State of the Ruby Nation: VM Choices
I have a concern that’s been niggling away at the back of my mind that I’d like to share with you. What’s concerning me is the state of the Ruby nation in respect of VMs (virtual machines). If I’m going to run Ruby I need something that understands my Ruby code and translates it so that my instructions get acted upon. That’s the job of a Ruby VM.
At the moment, I really don’t have too many choices of Ruby VM for serious, production quality endeavour. If I play for team Java, then I’m looking at JRuby. If Java isn’t involved, then I’m looking at some variant of Ruby 1.8 (MRI) depending on vulnerability issues. In the future this is not going to be the case.
There are new kids appearing on the block, the most prominent of which seem to be: MRI + YARV, Rubinius and IronRuby (a.k.a Ruby.NET). I’m not including JRuby in this list because I consider it to be an established player.
Let me make something quite clear before I continue. I am not looking at this from the perspective of a developer. As a developer I like choices and I revel in new challenges. However, if I am the Chief Technical Officer (CTO) of a corporation, my priorities are going to be different. I’m going to have to make sound decisions that are good for the business and I’m going to have to justify those decisions in order to get the hard cash needed to implement them. Above all, I’m going to make decisions that, hopefully, won’t get me fired. It is with my CTO hat on that I address the Ruby VM issue.
The three VM implementations that I listed above are in development, but are making fairly rapid progress. When they are ready for prime time what am I going to choose?
Will I choose the new and improved MRI with added YARV, developed by members of the original Ruby (MRI) team? Or will I choose Rubinius backed by the prodigious talents at Engine Yard? Or will I go for IronRuby if I’m in a .NET shop? Maybe something else will be vying for my attention and I’ll plump for that.
Truth is, it doesn’t matter does it? I think that what matters is that Ruby code runs as expected regardless of VM. If the respective creators of Ruby VMs continue to work with that idea in mind everything will be rosy in the Ruby garden. If it gets to the point where I can’t run my code reliably on any one of the major Ruby VMs, then there is going to be some significant turbulence in the Rubyverse.
As a CTO, I want to know that systems can be written to do what was intended within budget and on time. With competent development teams and practicable methods, the Ruby language should enable me to achieve those goals more often than not. If things go wrong, I want to be able to call upon someone to fix them if the answers can’t be found in-house. I do not want to have to swap one Ruby VM for another, because anytime I need to do that, Ruby is off the language menu.
