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