The Numbers Game

As a fairly content Java programmer, I really didn't go searching for an alternative. In some ways, Rails found me. Dave Thomas and I speak at the same conference. I taught several sessions on the Spring framework with Hibernate, and I was very happy with my productivity. Of course, compared with EJB, I was very productive. Dave pointed out that even in Hibernate with Spring, you tend to repeat yourself on a fairly regular basis.

I reflected on David's comments. To make a persistent domain model, you need to specify a database table with its fields and indexes, specify an object domain model with a class (repeating yourself) and a field as an attribute (repeating yourself), and add accessors for that field (repeating again and again). Then, you need to build a mapping with the database table (repeating again) and the class name (and yet again). Finally, your mapping must specify each database column and the corresponding database field (repeating each column twice more). Of course, most sane Java developers do not do all of that repeating. They let the tools do most of it for them, but now your programming model dictates your tool set, your development experience, and generates more lines of code to maintain. I came to the conclusion that ORM makes sense when the domain model and object model are sufficiently different, and I decided I'd take the slight productivity hit and be compensated with better performance and the possibilities of better mapping.

A Blinding Flash of Insight

As I've said, I worked with a company that builds safety software for a manufacturing plant. We effectively build a web user interface to manage a complex domain model. We decided to build this application with a lightweight Java stack of Spring, Hibernate, and Web Work. We moved pretty quickly, and were pleased with our progress. We were proud of our accomplishments, because we'd rewritten a one-year Microsoft application in four months with Java. Naturally, as we accumulated a bigger code base, coding began to take longer.

Over time, Dave's arguments nagged at my subconscious. Dave and my business partner had the same conversations. As luck would have it, over the same week, we tried building a part of the application in Rails. I banged out the model and scaffolding in a couple of days. With his stronger HTML experience, Justin got further than I did. He actually implemented the whole application in Rails in four nights. The Rails version shocked us in another wayit was actually faster!

Justin Gehtland: A Ruby on Rails Case Study

Coauthor of Better, Faster, Lighter Java

Justin Gehtland is the co-founder of Relevance, a consulting/training organization based in Durham, North Carolina. He's the coauthor of the Jolt-winning book, Better, Faster, Lighter Java, and has been developing applications of all sizes since the early 1990s. Over the last six years, he has delivered products using Java, .NET, LAMP, and now, Ruby on Rails.

You've recently moved a Java project to Ruby on Rails. What Java frameworks did the application use?	JG: The original stack was the usual suspects in the lightweight movement: Spring and Hibernate, plus a little JSTL on the frontend (so that the end customers could more easily customize the interface). I was using the ACEGI security framework for authentication and authorization, but only to authenticate against a local database of accounts.
What surprised you the most about the experience?	JG: After porting the app and talking about the experience, I was really surprised by the heated discussion it generated. There's that old saw about disruptive technologies; if the temperature gauge on the discussion is any indication, Rails is clearly in the disruptive category. From a technology perspective, I was surprised at the level of performance I was able to achieve. The Rails version of the app was fast, and faster even than the original Java version. That's partially due to a better understanding of the domain (rewrites always take lessons learned into account), partially due to a lack of performance tuning on the original stack, but mostly due to the fact that the performance gains with Rails are easy to achieve. The page and action caching strategies are right at the surface, and it's easy to manage their life cycle. I was able to max out the web server's ability to serve pages. I literally couldn't get it to go any faster.
Is Rails ready to usurp Java?	JG: Ruby isn't going to outstrip Java on a straight road. The JVM is tuned, and tuned, and tuned again to optimize byte code execution. But Ruby on Rails shines on the turns. Its integrated stack, dynamic language, and lack of a write/compile/test/deploy cycle means it handles better. For this application, it was like racing a Miata against a funny car on a mountain road. The funny car has more horsepower, but it just ends up driving straight all the time.
What are the top three things that made Ruby so much more productive?	JG: I'd have to say that the dedication to smart defaults is the primary benefit to Ruby on Rails. Ben Galbraith has said it several times, and I concur. Since Rails always lets you override any of its defaults, you are never in danger of getting stuck in a corner, but for the most part, you can create an application and ignore 90% of what would be surfaced in configuration files in another framework. Second, I really was surprised at how much of a difference the lack of the configure/compile/deploy/test cycle really makes. Saving a change and launching the tests while reloading the browser just seemed so instantaneous comparatively. I don't know that it made me more productive, but it made me feel more productive. Lastly, the dynamic nature of Ruby really shined for me. I did need some common pieces of functionality in the app that really belonged back at the framework level. Instead of having to delve into the source to add them, I just extended the classes I needed to at runtime. That kind of extensibility is anathema (and usually impossible) in a more statically typed language.

Making the Commitment

Of course, playing with a prototype and getting a customer to switch from tried and proven Java to a relatively unknown framework on an unknown language was an altogether different proposition. I had a conversation with the start-up's owner, and the results surprised me. He jumped at the chance to move. I guess I shouldn't be surprised. We simply couldn't ignore the differences in raw productivity between the frameworks.

In a start-up environment, productivity rules all other concerns. Since you don't often have the resources of your competition, you need to iterate fast. You can get some leverage by working longer hours and cutting bureaucracy. If you can generate an edge with technology, you've got to take that opportunity. In an increasingly competitive global landscape, we'll all need to act more like start-ups. If a framework makes you a mere 120% faster, you might be tempted to stay with a safer language like Java. But if you can be 400% faster or more, I don't think you can ignore the difference.

Remember, my premise is that Java is drifting away from its base. Most of us need to build web applications on relational databases. Language issues are important, but Java's drivers are so focused on hard-core enterprise problems that they're not making any progress on this simple core problem. If Rails doesn't step into this gap, something else will.

Some Numbers

I'm going to give you some performance and productivity numbers based on experience. I recognize the numbers are imperfect, for a whole lot of reasons. In some ways, the deck was stacked against Rails:

The Ruby application implemented more customer requirements. By the time Justin realized that his experience was important, he'd implemented some features that never made it into the Java version.
Justin was a recognized expert in Java, but had never used Ruby in a project, and had never used Rails. He wrote a Spring book, and he taught two weekend sessions 16 times per year for Hibernate.
The Rails framework has some design philosophies that are unfamiliar to Java developers.

More importantly, some of the factors worked against Java in the implementation:

The Java code was in no way fully tuned. The Java apps were much harder to tune, so we didn't get as far. We'd only started to look into performance. (The Ruby code was not fully tuned either, but its default implementation performs quite well with only some minor tweaks.)
We had already implemented the problem once, so the Ruby implementation had the benefit of some experience. The dramatic difference in application structure tempers this somewhat, but the user interface was nearly identical.
Justin did not have a chance to implement all possible tuning scenarios in all possible environments. The Java version used Tomcat on an Apple iBook instead of Resin or something faster. Justin just made a few simple tests.
The caching models are fundamentally different, and are far easier to tune on Rails.

Still, with Ruby, we develop faster; we're probably four or five times as productive. Table 7-1 shows the raw productivity metrics. We write less code. There's less code to maintain. With this type of increase in our cycle time, the customer is much happier, and we can better react to last-minute changes. Our test code is every bit as rich, and probably more so.

Table 7-1. Productivity metrics

Metric	Java	Ruby
	Spring/Hibernate	Rails
Time to market	4 months, approximately 20 hours/week	4 nights (5 hours/night)
Lines of code	3,293	1,164
Lines of configuration	1,161	113
Number of classes/methods	62/549	55/126

Table 7-2 shows the performance numbers. They're probably a little more controversial. I'm not trying to show that a Ruby application will always be faster than a Java application. I'm just showing that in this case, Ruby is fast enough, and it took almost no time or experience to get to this point.

Table 7-2. Difference in performance between untuned versions of a Java application after we moved it to Ruby on Rails

Metric (requests per second)	Java Spring/Hibernate	Ruby Rails
User scenario 1 (100 runs) (no preexisting cache)	71.89	75.59
User scenario 1 (100 runs) (with preexisting cache)	80.86	174.39
User scenario 2 (100 runs) (no preexisting cache)	80.86	62.50
User scenario 2 (100 runs) (with preexisting cache)	88.97	1,785.15

To be clear, in no way is Justin claiming that we've done everything possible to tune the Java application. The point here is that tuning Rails to this level was nearly effortless, and tuning the Java examples requires much more skill, time, and effort. The Ruby version is fast enough to meet requirements, with very little additional effort.

The Community Response

When Justin published this experience, followed by supporting data across two blogs,^[*] the Java community lashed out with surprising vigor. It's ironic, because Justin was completely honest with his numbers, and he presented performance numbers only after he was challenged by the community. You probably know that backlash will be particularly strong around disruptive technologies. In this case, the backlash may well be justified, because Rails is a credible threat to Java in some important niches, and it's likely to get stronger quickly. If Rails does happen, a whole lot of knowledge can get marginalized in a hurry.

^[*] Justin Gehtland, Weblogs for Relevance, LLC (April 2005); http://www.relevancellc.com/blogs. I *heart* rails; Some Numbers at Last.

Look, I'm not saying that this data is scientific, thorough, or even broadly applicable to other applications. It just reflects our experience, and as such, it is compelling. It tells me that Rails is productive, is fast enough to get the job done, generates less code, and is much easier to tune. The data does not prove but strongly suggests a few other hints as well. Rails could well be much more productive than Java for a pretty wide class of applications. Rails can handle sophisticated domains with inheritance and relationships. And Rails is often enough to get the job done.

Keep an open mind. Judge for yourself.

[Previous] [TOC] [Next]