| How can you say that JRuby can't innovate? JRuby is far from stagnating. 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. |
My reply was meant for people that questioned a project like Rubinius when there is JRuby around. And you're right, I only have a very high-level overview of the problems you're encountering, mostly being just educated (or maybe not) guesses.
The reason for my rant is that Rubinius is awesome too and I would rather see Rubinius replace MRI as THE reference implementation - since it's a more flexible environment built from scratch, people will be able to experiment with features more easily.
I do however object to one thing you said - continuations are awesome and I'm sad they got pulled from Rubinius.