The Impending Ruby Fracture

There are 4 Ruby execution environments currently under very active development: YARV (the blessed Ruby VM, 1 developer at a University, 3 years in development so far and garbage collection still doesn't work,) JRuby (Ruby that runs on the JVM, 3 full time people, 2 of whom are Sun employees, and one of whom is currently writing the Ruby 1.8 spec), Ruby.Net (Ruby that runs on the .Net VM, 1 full time coder who was recently hired by Microsoft), and Rubineus (written by a frickin' smart former sys-admin who loves Ruby, picked up the Smalltalk Blue Book and is implementing a Ruby VM & JIT in Ruby that's almost self-compiling.) I'll give more in depth descriptions of my impressions of each of the teams in a minute.

Matz is completely uninterested in making Ruby appeal to enterprise customers. "The enterprise guys can go and do their enterprisy things... that's fine to do." There was no real interest in appealing to them, or really anyone outside of the current Ruby users and the Rails team. In order to move to the "next level", I believe Ruby needs to address the needs of the other 90% of the market.

Matz said on at least 7 occasions that people should code to Ruby 1.8 because that's where Ruby will be for a very long time (although he promised Ruby 1.9 for Christmas 2007.)

JRuby and Rubineus are coded to 1.8 and focusing on supporting 1.8 and Rails on 1.8 as their benchmark (Rails, Camping and a few other popular packages are the "test suite" being used to validate these Ruby runners.)

Time for a change of subject... the Ruby execution environments.

There's Matz' Ruby 1.9. 1.9 is very late. There's 1 person working on the VM code (Ruby 1.8 and prior run the interpreter from the Abstract Syntax Tree generated by the Lex/Yacc generated parser.) The VM is very late, buggy (no functional garbage collection.) Matz has said that 1.9 would run native threads (rather than the current green threads) but YARV will ship with green threads because it's too difficult to maintain compatibility with all the C extensions that have been written for green threads. There's no spec for 1.9 and Matz doesn't seem to have a vision for it other than the version of Ruby that runs on YARV (the blessed 1.9 VM.)

JRuby is in active development by 3 developers, 2 of whom are now Sun employees. The lead is a guy named Charles Nutter. Charles struck me as good at developing specs and coding to them (Charles is leading the effort to write the Ruby 1.8 spec.) Charles has spent the last 3 weeks working on JRuby performance improvements. Every day or two, he announces a commit that gets a 2%-4% performance improvement. That really adds up over a couple of weeks. This is an indication of the kind of developer Charles is. Olla is the non-Sun developer on the JRuby team. He's the guy who hits triples and home runs. He'll make a commit that fixes 35 defects and adds 4 new features. His commits are less frequent and predictable that Charles', but the two seem to balance each other very well. Charles is also very diplomatic (he was an architect for a professional services company before going to Sun.) Charles also understands that challenges of developing and deploying large-scale projects and has used Java's excellent set of tools for the deployment side of a project.

Ruby.NET is in active development by 1 developer at Microsoft. He was doing the project on the side (like the JRuby guys) and was recently hired into Microsoft. I only spent a few minutes chatting with the Ruby.NET developer. If Microsoft is serious about Ruby, they will make it happen, but the existing developer may be an experiment in bringing another dynamic language guy into the fold to try to get some of that Visual Basic magic back.

Evan Phoenix is a sys-admin turned hard-core programmer. He has been working on a Ruby runtime in the spirit of a Smalltalk runtime called Rubeneus. He read the Smalltalk blue book and used it as a basis for writing a Ruby virtual machine in Ruby. He's injected a little bit of JIT magic into the mix such that the Ruby byte-code VM dynamically creates C code for certain high-traffic methods and thus he gets some real performance. He's re-written some of the C classes (e.g., Array) in Ruby and oddly enough gets near C performance from his Ruby implementation. Rubeneus has pluggable garbage collection, pluggable code generation, a pluggable threading model etc. Evan thinks he'll have something that can run Camping (a very light weight web framework) by mid-2007. I'm betting that until the JVM has dynamic method dispatching, this will be the fastest Ruby implementation. I chatted with Evan. He's a crazy-smart guy. I explained to him how Java applications were deployed (WAR files) and how app servers could load multiple versions of classes into the same running VM such that different apps could have version specific libraries. He immediately "got it" (being a former sys-admin helps people understand the deployment issues) and told me the changes he'd need to make to accommodate a "classloader" style system of loading classes so a single Rubeneus instance could run multiple apps with multiple libraries.

So, there are 4 Ruby runtimes in various states of being built. They all (except for 1.9) will be fully compatible with 1.8 and they will all run Rails just fine. So, what's going to happen when some enterprise customer wants interfaces or some other optional typing mechanism (Matz is dead-set against any form of non-duck-typing in Ruby.) What happens when some enterprise customer wants to close open classes from modification from just any other class (oh, you mean a library that we did a GEM update that just re-wrote our code to send all strings that match /[0-9]{3}-[0-9]{2}-[0-9]{4}/ to some server hosted in Russia?!?) What happens is the JRuby team integrates Java's sandbox model into Ruby. It means that the .Net guys do their security magic. Who knows what Evan will do. It's unclear what Matz will do. Maybe the 37 Signals guys say, "this is a real problem and something has to be done." Maybe Matz listens or maybe the Rails guys just team up with another vendor that provides more enterprisey, more predictable support for the runtime.

At the core, I think Ruby is defined by Rails. Sooner or later, the Rails guys will realize they're the dog and start finding a tail that's easier to wag for the customers with lots of money. That will likely lead to fractured Ruby syntax and fractured Ruby dialects.

My 2 cents.

Thanks,

David