[From Java to Ruby](http://www.pragmaticprogrammer.com/titles/fr_j2r/) nears general availability and this is the third and final series on different perspectives for Java and Ruby. Most of the FUD that’s out there for any technology is targeted not at developers, but the people deciding on a platform. That person is the target of From Java to Ruby. In many ways, writing the book was an exercise in dispelling myths. All of these bullets but one are fud toward Ruby or Rails. I still don’t think Ruby has a proportionate voice. But the first myth is FUD about Java, and every bit as damaging as any of the other bullets on this list.
1. Rails can be all things to all people.
——————-
Disruptive technologies are disruptive because they are marketable, not necessarily because they are technically sound. EJB was disruptive, making it difficult for other types of persistence and middleware to succeed in the marketplace. That technology sucked, and only now, eight years after the first spec, are there hopes that we may have gotten it right. Rails is disruptive. If you can’t see that, you aren’t paying attention. But Rails will never be all things to all people. [DHH](http://loudthinking.com) is on record saying he never intended Rails to be all things to all people. It’s just a better way to build database backed, web apps. Rails will grow, and has grown, out of that niche in spots. But overselling Rails as an infinitely productive, infinitely scalable solution just leads to the perception that we’ve been down this road before. And I’m on record saying that Java is not dead. (I say dead like COBOL, not like Elvis.) Java will never be completely replaced, and I’d pick Java to do mobile computing, many kinds of enterprise integration (such as two phased commit). But I do believe that Java’s the wrong choice for the typical green-field, database backed web app. There’s just too much baggage, and other technologies are better fits in this space.
2. Ruby on Rails has not been proven scalable.
———————————
This half-truth is a common way to imply that there’s something inherently wrong with Ruby’s scalability model. Actually, we were saying the same thing about Java ten years ago. Truth be told, the shared-nothing architecture behind Rails has been well proven. You won’t get infinite scalability, but you’ll get enough. Some of the largest Internet sites were built on Lamp technologies including Python and Perl. The language is rarely the bottleneck for classic database-backed apps. The database is. This argument reminds me of the negative spin Hibernate got over reflection. In truth, because the database and the network were the bottleneck, reflection was plenty fast enough. In truth, Ruby on Rails should scale well. With caching turned on, it can scale very well. But we don’t have a massive deployment, on the order of e-bay, yet. Why? Ruby on Rails is simply too new. Version 1.0 is less than a year old. But we do have plenty of examples showing moderate scalability, thanks to 37signals.
3. Rails is just another quick and dirty scripting language.
——————————
This pure-FUD myth is a real laugher that comes in many forms. Some say “I defy you to find a Ruby deployment more than 50,000 lines of code. " Others say "Rails is just Perl on steroids.” (You could do worse.) My favorite version is “VisualBasic grew fast too until we couldn’t maintain the code.” All of these suggestions ignore one common reality.
Ruby is in many ways cleaner than Java. It’s a purely object oriented language. (You won’t see a common method repeated in Array nine times for each primitive type.) It has advanced abstractions that Java doesn’t. Java framework developers are only now beginning to realize that [dulling the knives in the kitchen](http://pizzatoday.com/features_articles.shtml?article=NDE3MHN1cGVyNDE2N3NlY3JldDQxNzQ=) is not the best way to protect the cooks:
- Java developers are seeking more and more ways to loosen coupling by defeating Java’s typing model and delaying binding. [Dependency injection frameworks](springframework.org) fundamentally loosens binding through XML, and is critical in Java, but borderline unnecessary in Ruby. (Dependency injection tends to happen thousands of times, without a framework.)
- Java developers are understanding that some of the duller knives need to be sharpened. Some of the fiercest debates have been related to checked vs. unchecked system exceptions, the overuse of Finally in Java, and the static typing model.
- Java’s developers are starting to clammer for some higher level abstractions, like [continuations](http://kasparov.skife.org/blog/src/java/cont-jsr.html).
With the amount of energy around DSL, POJOs and metaprogramming, you’d think that it’s just a matter of time until we adopt a language built from the ground up to handle such things. After 35 years, we’re finally ready for a pure oo language.
4. Conservative companies would never use Rails.
—————————-
I have found the opposite to be true. Some backward countries skipped wired telephones and went directly to cellular technologies. In the same way, if the price is right, conservative companies will skip a generation to give Rails a shot. Within the right problem context, it costs much less to build the same application with Ruby on Rails. Productivity, both short and long term, rules. Java has always countered quick and dirty with better long-term maintenance prospects. But Ruby is quick and clean. My experience so far is that maintaining my Ruby code is far easier than maintaining my Java code.
5. Ruby is only about Rails.
——————————————
Some of the people I interviewed in Beyond Java and From Java to Ruby use Ruby often for tasks beyond the Rails domain. Ruby is a fantastic language for scripting, testing, metaprogramming, builds, and many other problems. Rails serves as the catalyst and the flagship framework for Ruby. But in 10 years, excellent frameworks have obviously been built. Rake, gems, REXML, and ActiveRecord are reason enough to use Ruby without the whole integrated Rails stack.
Ruby will certainly not displace Java. But Ruby has a role to play. And it’s probably more prominent than the most ardent critics will ever be able to stomach. But remember: this kind of FUD is inevitable for an emerging language with the potential for this kind of disruption. If you’ve been around for 10 years, you’re familiar with it. After all, the earliest Java critics said you’d never be able to run Java with acceptable performance on the server.