The SquizLog

Re: The appeal of Ruby over Java

Earlier today I read with interest a list of reasons why Ruby on Rails appeals to Todd Huss more than Java. Like Todd, I've been experimenting with Rails but Java continues to pay my bills and I still enjoy developing J2EE apps. For a while I've been mulling over what I see as the strengths of Rails compared to J2EE. Now let's see if I can enumerate a few from my experience.

First of all, some background. Over the last few months I've been developing a Rails app that I've called, for want of a more inspired name, Cricket Coach Helper. I've enjoyed it because it has given me a chance to get my hands dirty with Rails (beyond following the example in the book) and in the process build an application that has proved quite useful to me. For those of you familiar with cricket, the app has allowed me to record details of players, competitions, fixtures, match scores and to generate statistics (e.g. batting, bowling, fielding and partnerships) for the team that I have been coaching.

So what impressions of Rails has this experience left me with?

1. The quick start to development was a delight!

   Installing Rails was a breeze. Then in a short time I had run rails crichelp to generate the structure of my application, created my development database with a Players table, configured my database.yml file, run ruby script/generate scaffold Player Admin::Player to generate CRUD code for the Players table and pointed my browser to http://localhost:3000/crichelp. I was ready to test my first iteration!

2. Incremental development and learning was usually quick and easy.

   As I progressed beyond some straightforward CRUD functions I soon encountered use cases where a scaffold didn't cut the mustard. But, like Todd, I found that I could learn more details of the Rails framework as I needed them. Having the PDF versions of both the Rails book and PickAxe handy has been invaluable. Using WEBrick as a development web server also smoothed the way. And having the structure of the application pre-defined by Rails allowed me to concentrate on incrementing the application's functions rather than refactoring infrastructure code.

3. I like the simplicity of Active Record.

   I think the way Active Record integrates the tables with the Ruby model classes is simple, clean and elegant. The way it infers attribute names from column names is liberating when compared to Java equivalents (I know Hibernate and TopLink have more flexibility to overcome impedence mismatches but how often is that really a problem?). And having the relationship declarations (e.g. has_many) together with additional methods that may be required all in the same Ruby class makes so much sense (It's an unfair comparison but I've just had an awful flashback to generating CMP Entity Beans!).

4. It has been a delight to improve my working knowledge of Ruby.

   As I get to know Ruby better one reason I like it so much is because it reminds me of Smalltalk. Blocks and closures are sadly missing from Java. And I think duck typing works well too. However, I'm well aware of the debates about the relative merits of strong and weak typing. Anyway, I like Ruby. For example, it allows the programmer to manipulate collections so much more elegantly and tersely than Java (even Java 5).

5. For relatively simple apps I'm happy with the Rails MVC approach.

   The convention over configuration approach is definitely a strength of Rails. The structure to support separation of MVC concerns is a given. So there's no mucking about at the start of a project making decisions about standards to ensure MVC concerns are separated using a consistent approach. That's all good as long as Rails supports the technical requirements, which is not always going to be the case (e.g. responding to asynchronous messages is a case that is well supported in J2EE by JMS and message-driven beans).

6. Using rake for testing the model worked well.

   The use of rake for automated unit testing of the model was similar in many ways to my experience of JUnit. However, I was particularly impressed with the way fixtures have been built into Rails. This is another good practical example of the productivity to be gained from the convention over configuration philosophy. On the downside, and I know this is trivial, I did miss seeing the JUnit green bar!

7. Despite the power of TextMate I found myself wanting an IDE.

   TextMate is an excellent code editor for Rails development, especially because it recognises Ruby and Rails syntax. I definitely found it superior to using Eclipse with the Ruby plugin, mainly because TextMate shows Embedded Ruby syntax in the view files whereas the Eclipse Ruby plugin is dumb as far as rhtml files are concerned. However, I could not help but yearn for the helpful features of an IDE like Eclipse. Simply being able to use code complete in Eclipse to find methods quickly or in conjunction with code templates is such a productivity booster. Anyone who argues that languages like Ruby, Python or Groovy are more productive because you have to type less is being blind to the huge benefits of a sophisticated IDE.

8. I'm still not convinced about the ability of Rails to scale.

   I need to research this topic more but to date I haven't seen a rigorous analysis of the ability of Rails to scale compared with J2EE. This is any easy target for those defending J2EE against Rails and I don't think reporting that a Rails site handled 2.5 million requests in a day is helpful or rigorous.

9. There does not appear to be good Apache support for Rails.

   This is another topic that I need to research more. However, from what I have read, Apache's support for running Rails via FastCGI is problematic. I know that lighttpd is an alternative for production deployment but if it is problematic to run Rails on the world's most popular web server that would appear to be a limiting factor to widespread adoption. As I said, I need to learn more about Rails deployment so if you think I'm talking rubbish here, I'm happy for you to politely correct me.

10. Rails and J2EE both have strengths and weaknesses.

    I think Rails has a good fit for relatively simple web applications that typically provide a web UI to a database. I've seen web applications developed using J2EE for which that technology was an unnecessarily complex choice. Rails offers a promising alternative now. However, J2EE is not going to go away any time soon. It is a mature technology, is undergoing significant improvements (e.g. EJB 3.0) and is trusted by many corporations who have made a significant investment in it (wait on, that sounds like a defence for COBOL!). And, for some applications, it will be a more appropriate choice than Rails.

There you have it. Ten impressions from my experience with Rails so far. It will be interesting to see how much of an impression Rails makes on the market over the next year or two.