That said, there's certainly domains where JRuby is not a great fit. C extension-heavy systems are one; because C extensions are so crippling to more modern VMs like the JVM or Rubinius, you're better off using the implementation the C API was designed for (MRI). Or if Rubinius suits your needs and C extensions work well enough, I'll recommend Rubinius over JRuby any day. I hate C extensions, or at least I hate them in the form they exist in MRI, since they're invasive and damaging to modern VM features like good GC and concurrent threads.

In any case, it's worth seeing if FFI (the Ruby API that Rubinius pioneered and JRuby made generally available) serves your purposes, because it works extremely well in JRuby and requires no C extension support. And I'd suggest you actually give JRuby a try; it's so much more than "Ruby for Java interop" and may work better as a "plain old Ruby impl" than you expect.

If you need C-extensions, well, there you go. Rubinius as a better MRI I totally get/agree with.

I think we agree on that as a good reason for the season for Rubinius.

It'd just be nice for EY to put up a "Why Rubinius?" page. And further, a "Which VM best targets my project? JRuby or Rubinius?" page would make me very happy. I can't imagine it could hurt the adoption of either.

* Can't have multiple VMs in process, because C exts load all their state into C globals * Can't run them concurrently, because they can't be trusted not to segfault * Don't participate well in modern GCs, so they have significantly higher call overhead in JRuby or Rubinius than they do in MRI

FFI is a better option in almost every case, although it is admittedly a much trickier path to cross-platform library binding. The best thing the Ruby community could do to move Ruby forward is to either come up with a better C API or start using FFI for everything. C exts suck.