JRuby is among the fastest, gives you access to a
massive amount of OSS and infrastructure, and fixes
Ruby's threading.
Being faster than MRI on some tests doesn't say much because from a performance standpoint MRI is a piece of shit.If you're looking for a good reason for why Rubinius is important - JRuby cannot innovate and as Ruby will see progress, JRuby is bound to stagnate. For example, continuations are really useful in many contexts, yet JRuby has no chance to actually implement continuations with decent performance overhead. Also, the Refinements proposal for Ruby 2.0 is a bitch to implement on JRuby. Even the Fibers in Ruby 1.9 come with a lot of overhead. The reason for that is because JRuby inherits all the JVM's flaws. The JVM was designed for Java. The optimizations it makes function best in the context of Java. The type system is the one from Java and working around it is extremely painful. The garbage-collector itself is designed for Java. It has rough limitations on what it allows and what it doesn't allow. And when I'm saying Java, I'm saying Oracle's Java SE, or OpenJDK, not Android, not Java ME. And considering that Apache Harmony does not have the same JIT-ing characteristics of Oracle's Java SE, while I haven't seen any benchmarks I'm willing to bet the performance is much worse. JRuby may shine among the current bunch of VMs, but that doesn't say much, because on top of the JVM in its current incarnation (including the invokedynamic additions) you'll never be able to achieve the performance Smaltalk was capable of. If you care about Ruby as a language, caring about a VM like Rubinius is a no-brainer. |
Continuations are almost never used, and in the rare cases where they are used they are almost always more straightforwardly replaced by non-continuation alternatives. FWIW, Rubinius doesn't support continuations either. It may some day...and so may the JVM.
Refinements will be easy to implement in JRuby. I've implemented prototypes of it in hours of effort. You don't know what you're talking about.
Fibers perform well in JRuby, but necessarily are implemented with native threads. There's work to add full VM-level coroutines in Java 8, and you can build versions of OpenJDK with coroutine support already. Once that's there, we will have substantially faster Fibers than Ruby 1.9.
JRuby supports all of Ruby's class structures and features atop the JVM. The JVM's type model does not hinder us implementing Ruby's class model.
The JVM optimizes calls; Ruby makes lots of calls. The JVM does an outstanding job of optimizing Ruby code in JRuby, and invokedynamic is already making small Ruby benchmarks in JRuby run within a few * the speed of an equivalent Java implementation. That's incredible. I've actually sat and read the assembly code Hotspot outputs and worked steadily to remove as much overhead as possible, with or without invokedynamic. I guarantee you the JVM is going to optimize Ruby like gangbusters. You don't know what you're talking about.
I'm not sure what Smalltalk performance you're talking about. No Smalltalk implementation has managed to approach the performance of current JVMs, and JRuby is starting to approach the performance of Java when using invokedynamic.
If you care about Ruby as a language, supporting many implementations and caring about all of them is a no-brainer. Slagging off one implementation you obviously have no correct facts about shows you don't care about Ruby as much as you harbor bigotry against one implementation.