ThoughtWorks wants Ruby to win. By 'win', I mean become a major software development language, where it is the default choice for many application types. What I don't mean by 'win' is to beat some other specific language, particularly the dynamic languages like Python, Groovy, etc..., which we believe offer clear advantages in terms of Agile software development. Truth be told, the rise of one technology often necessitates the decline or sublimation of another, but philosophically, competition is not what we're after. ThoughtWorks is pushing Ruby on all cylinders because we want to change the face of software development, and we believe Matz created a language with a semantic elegance, culture, and community that matches our values.

That same noncompetitive philosophy applies to Ruby's many language implementations. Over the last few months, ThoughtWorks has said a lot of good things about JRuby -- we even offer commercial support for it. ThoughtWorks believes that JRuby has a great enterprise deployment and code reuse story. However, we want to clear up a misconception that we've admittedly created. Our support for JRuby doesn't imply that we want it to 'win' vs. the other implementations. In fact, we're excited about YARV/Ruby 1.9.1, Rubinius, IronRuby, XRuby, and Gardens Point Ruby. (As someone who started writing Perl as a kid, I'm hoping that Cardinal/the Parrot implementation gets traction someday too.) The more implementations that comply with what Matz deems the language, the better. Multiple implementations will provide different tools to solve interesting and varied problems -- a definite plus from the engineering side. For example, JRuby solves problems for Mingle, our collaboration software, in terms of installation, deployment, and code obfuscation. But we still develop Mingle in MRI (Matz’s Ruby Interpreter) because we can avoid the JVM startup time.

Rubinius and YARV/Ruby 1.9.1 are headed for some significant milestones during the rest of this year that we're watching. Ruby 1.9 looks to have some significant performance benefits. We like Rubinius' approach, and who knows, we could create a Rubinius version of the RubyWorks Production Stack in the near future. Also, Microsoft continues to do some really interesting things with the DLR and IronRuby, which adds great strength to our Ruby in the enterprise story.

All that to say, ThoughtWorks is language implementation neutral. We haven't done the best job of expressing that, but our approach has always been to use the best tool for the job so to speak. ThoughtWorks will continue to shout the benefits of JRuby from the hills because we think it makes Ruby accessible to millions of Java developers at corporations around the world. However, our excitement around JRuby doesn't mean that we're not rooting for the other implementations too.