I'm sure many of you recall last year's presentation "Ruby: Past, Present, Future". It took place almost a full year ago, on June 16th. At the time, we noted how several of our main subjects under discussion could evolve in different ways. Let us review and reflect on those subjects once more.
First off, let's get one major subject out of the way: the Ruby language itself. That hasn't changed much, and not likely that it will. The design is solid, or at least solidified. Much as it was a year ago, changes planned for Ruby 2.0 are small, incremental; and even of those, the majority count as wart-fixers (e.g. less surprising handling of closure scopes). So everything we said about Ruby as a language a year ago, is still as true today.
Now for the other major subject of that presentation: implementation. There, we have many changes and developments.
_YARV_ is still looming in the all-too-distant horizon, as predicted a year ago. There's a lot of interest in it, following the growing concerns over MRI (Mat'z Ruby Implementation,the current 1.8.x implementation everyone's using) performance. Just a few days ago there was another wave of speculation about Twitter abandoning Rails due to poor performance, and they're not the only ones.
YARV still, however, suffers from the same problems we discussed yesteryear, namely: lack of significant improvement over MRI. True, it is bytecode-compiled, and yes, it is faster and better than MRI. But not by much. Last year, this estimate was mostly a speculation, based on analysis of the architecture, but since that time YARV has reached an increasingly stable state, and benchmarks are becoming more meaningful. Results, as expected, are not exciting. YARV is generally no more than 50% faster than MRI.
Ruby needs to run at least several times faster to compete with even just some of the faster dynamic languages in its class (Python, PHP, Perl). YARV currently doesn't provide that, or anything really close to that, while several of those rivals are constantly improving their own VM performance, both evolutionary (with small incremental upgrades) and revolutionary (with ideas like JIT compilation, partial type declaration / inference etc.)
_JRuby_, as predicted, has continued its determined, stable progress towards a solid, fast (but not incredibly fast) Ruby implementation. At the time, we discussed at length how JRuby is evolutionary, rather than revolutionary; how it aims at modest goals ("faster than MRI", not "as fast as compiled C").
Very little of what JRuby does is experimental or ground-breaking. While this may sound unexciting, it also means there's not much soul-searching or basic research involved in the core parts of the project. JRuby has been progressing by slow, measured, but solid steps; and indeed, of all the projects we've discussed, it's currently in the best shape.
JRuby is currently a 1.8.x-compatible Ruby implementation. It runs Rails well. While it is not generally considered quite as fast as YARV in interpreted mode, it's running 1.8.x code, and not the unstable 1.9 version of the language. This makes JRuby the fastest viable 1.8.x platform, i.e. the best performing Ruby platform out there that's actually viable for production right now.
Consequently, there's growing interest in JRuby as a production Ruby platform. This is aided by its natural integration with the JVM, the Java libraries, applications and tool-chains. However, a major obstacle also stems from JRuby's slow, cautious progress - it's not the revolutionary Ruby implementations that users yearn for. Being generally a bit faster than MRI is certainly a great achievement for an implementation project, but doesn't make it an obvious choice over MRI; if you really care about performance, both are pretty slow.
_Rubinius_ has been through a lot this year, fulfilling at least one prediction we made about it: of the major re-implementation efforts, it's certainly walking the most interesting, twisted path.
A thorough survey of the twists and turns Rubinius went through is much beyond the scope of this post; for anyone truly interested in Rubinius, the recent presentation by Rubinius's lead developer, Evan Phoenix, at the Mountain West conference could serve as a good introduction. We'll only focus on a few short points.
Rubinius's original slogan has been "Ruby implemented in Ruby". Theoretically and practically, it is possible to build in a dynamic language a fast virtual machine to host itself. Smalltalk has already done that with the Smalltalk-80 design that dates back to the 80s. Some of these implementations are very fast compared to Ruby, while offering closely comparable levels of dynamism and flexibility. In fact, one way for Ruby's performance problems to end is by following Smalltalk's implementation strategies; the languages are similar enough from a performance-analysis point of view, to make that very feasible.
The project has gone through many changes and shifts during the last year. Just little more than a month ago, it was decided to completely rewrite one of its key parts - the Shotgun virtual machine (and in C++ instead of C). While there are many good reasons for the rewrite, it will still delay progress.
Rubinius is arguably still the most interesting Ruby implementation project around. JRuby deserves a lot of respect for becoming, slowly but steadily, the best currently-viable Ruby implementation. Rubinius definitely has a long way just to get to where JRuby is right now. But it has been getting a lot of attention and love, with several top notch Ruby hackers working on it full time.
The above covers the major implementations we discussed last year. Not much more is known or can be said about IronRuby; the same concerns we discussed last year were about as valid then as they are now.
Three new up-and-coming implementations that I would like to mention are HotRuby, IronMonkey and MagLev.
HotRuby is essentially a hack: you embed Ruby code in your DOM, which HotRuby then extracts and sends to the server for processing by Ruby 1.9 CGI. The results of the Ruby execution (all done on the server) are received at the client as JSON and acted upon by HotRuby. There was a lot of buzz about this about a month ago, and I'm not sure why. Notably John Resig (jQuery's lead developer) blogged about it, and it then got Slashdotted. One of the main points in the blog is that the whole setup is faster than the same code running locally Ruby 1.8.2, which shouldn't surprise anyone familiar with Ruby platforms who knows that 1.9 is significantly faster than 1.8.2 for comparable code. So maybe this whole thing was a misunderstanding. In any case, it's a nifty AJAX trick.
Hope you enjoyed reading all that, and take care,