At RailsConf 2008, Gemstone announced a new Ruby implementation, Maglev, to run on the company's existing SmallTalk VM. GemStone/S is also an object-cache and a distributed object-oriented data store capable to scaling to several petabytes of data, and it has been extended with extra bytecode to enable it to run Ruby applications, with a special focus on Ruby on Rails applications.

At the RailsConf presentation, Gemstone's Avi Bryant and Bob Walker explained how Maglev would work, and presented some performance figures based on an incomplete implementation. According to those figures, Maglev will perform several times faster than most existing Ruby implementations. As well, Maglev is able to take advantage of the GemStone's transactional data store, allowing it to share data among Ruby and Rails applications.

While the impressive performance numbers were reported in much of the Ruby press, they are hard to verify, writes Charles Nutter in a recent blog post, Maglev. He contrasts that with other Ruby implementations that not only are available for download, but that have also focused more on compatibility:

Rubinius and IronRuby teams have always considered compatibility as the primary goal. If you can't run Ruby apps, you're not Ruby, right? And so every step of the way, as they published performance results AND compatibility metrics, they've always been honest about the future...

Like the other impls, I'm excited that there's a new possibility for Ruby to succeed. A high performance, "scalable" Ruby implementation is certainly what this community needs. But unlike most of the other implementations, it seems like Maglev is pushing performance numbers without compatibility metrics; marketing before reality. Am I far off here?

Nutter points out that striving for greater compatibility does mean performance compromises on occasion, but that those compromises are worth making:

IronRuby has managed to get great performance on several benchmarks by leveraging the DLR and the excellent language implementation folks on the DLR and IronPython teams at Microsoft. So if nothing else, they've proven many of the "fast-bootstrapping" claims they've made about the DLR. And they've always been balanced in reporting results... That honesty has not gone unnoticed, and it shows a realism and humility that will ensure IronRuby's future; a realism that will ensure Ruby users who really want or need a .NET implementation will receive an excellent one...

JRuby, like IronRuby and Rubinius, has always focused first on compatibility. This means we're bending over backwards to make normal Ruby code run. So in many cases, we're doing more work than we need to, because compatibility has always been the primary goal. IronRuby and Rubinius will report the same process. Make it work, then make it fast. And both IronRuby and Rubinius are now starting to run Rails, so I think we've proven at least three times that this is the right approach...

Perhaps we should be focusing on the compatibility story over bleeding-edge early performance numbers; focusing on tangible steps toward the future... Maybe we should think more about the effect that broadcasting vaporware performance numbers will have on the community, rather than rushing to be the first to republish the latest numbers on the latest slides.

What do you think of Maglev?