On JRuby’s importance for the future of Ruby

In a recent blog entry, Charles Nutter argues about the importance of JRuby for Ruby’s adoption within the Enterprise. Or, in his own words:

The idea of “Enterprise Ruby” has become less repellant since Dave Thomas’s infamous keynote at RailsConf 2006. There are a lot of large, lumbering organizations out there that have yet to adopt any of the newer agile language/framework combinations, and Rails has most definitely led the way. I personally believe that in order for Ruby to become more than just a nice language with a great community, it needs to gain adoption in those organizations, and it needs to do it damn quickly. JRuby is by far the best way for that to happen.

He has a very good point. Working for IBM (it doesn’t get much more Enterprise than that) I can testify to the number of colleagues and partners who ask me questions like, “Can I interface Rails with Java?”, “Can I deploy it with WebSphere?” or “How can I generate a Rails WAR file?”. The answers to these and similar questions are all found in JRuby.

A couple of years ago I “toured” Canada, speaking at a few IBM, internal conferences. The vast majority of my attendees were experienced Java developers who were doing business consulting for IBM’s clients. They were all very enthusiastic about my presentation on Ruby and Rails. It was a break from J2EE’s complexity. These people were genuinely excited about the perspective of using Rails when doing client work.

Mid-conference, one attendant said to me, “This is cool, but they’ll never let us use this stuff”. And that’s when I reached for the JRuby slides. The mood in the room suddenly shifted. These developers started to think “OK, this could actually work”. At the end of my speech, most of the questions I received had to do with JRuby.

As I mentioned during that series of conferences “JRuby can be your gateway to introducing Rails into your workplace”. Many people within the Enterprise world don’t have an option. It’s either a JVM-based solution or they have to give up on Rails altogether.

JRuby is not only attractive to Ruby fans who’d like to use Ruby/Rails in certain work environments, it’s also appealing to those who are looking for an alternative to Java as a language. Here is where we could hit the jackpot in terms of Ruby’s adoption. There are countless Java programmers in the world. Convincing even just a fraction of them to switch would be enough to drastically increase the size of our community.

As Charles mentioned in his post, people can now pick between Scala, Clojure, Groovy, JRuby and Jython. I believe that the choice developers ultimately make boils down to three key usability aspects:

1. If I’m moving away from the complexity and limits of the Java programming language, I will most likely want to embrace something that is easy to use, yet also very powerful. JRuby, Jython and perhaps Groovy, have a major advantage in this regard. Most Java developers will find Scala and Clojure intimidating, in my opinion.
2. Java is one of the fastest languages out there. The speed of these implementations will have an impact on the sort of choice people ultimately end up making. Going from Java to JRuby can be a pretty dramatic decrease in speed. In this sense Scala has the upper hand. So I believe that continuing to improve JRuby’s performance will be key.
3. Java integration. How hard does this language make using libraries that I’m already used to? Are they easily wrapped or do I have to jump through hoops? I think JRuby does a pretty good job in this regard.

Charles’ team has been focusing on the right things. If I can be permitted one criticism though, it would be to avoid responding to every post that praises a competing implementation. Openly fighting against other implementations can backfire and looks unprofessional. I understand the desire to set the record straight and being competitive, but there is no reason to constantly point out that “these implementations are not done” every time an early project shows some form of promise or progress. Otherwise, it’s easy to come across as someone whose “heart turned black as coal, and who finds himself wishing bad luck towards other implementations”.

Today JRuby is an Enterprise-friendly alternative to Ruby MRI/KRI; and Charles is right, JRuby is important for Ruby’s future. It would however be wrong to assume that JRuby is the only sort of future for Ruby and that C/C++ based implementations are becoming irrelevant. Ruby has never been a zero-sum game. Plurality is a substantial part of what the Ruby ecosystem is all about.

Finally, let me conclude by congratulating the JRuby team, who have just been hired by Engine Yard. I think this could be a very strategic move for both JRuby and Engine Yard.