Beyond Java - Bruce Tate [66]
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.
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.