JRuby is pretty unique among non-reference language implementations in that it's often more performant, powerful, and stable than the standard Ruby implementations. It's been rock-solid for us recently, and integrates with Java surprisingly well.
I often think that the Ruby world would be a more productive place if the original implementation had leveraged the JVM.
And the Torquebox team (Torquebox being a JRuby Rack app server using JBoss) also did some benchmarks and discovered (surprise, surprise) that Torquebox on JRuby significantly outperforms the alternatives on 1.9.2:
One of the nicest things about JRuby (apart from performance and stability) is that you get easy access to all the wonderful Java libraries out there, which you can use with Ruby style syntax. These are often far higher quality than the Ruby equivalent, if that Ruby equivalent exists in the first place.
I've heard this argument a few times. As someone that's not new to Ruby but hasn't touched Java, can you elaborate as to what these awesome Java libraries are?
There's basically a library for everything. Creating or rendering PDFs? Several choices. Converting document formats? Choose the one with the license you like the most. Extracting data? Any format you want.
Then there's algorithms, support for just about any protocol under the sun. And the Java standard library is surprisingly complete as well - what you need might even be installed with your JVM.
Try googling for a Java library next time you think of something you want to do.
Our app sells to the finance vertical, so we deliver a lot of data in Excel. There is a really great project called Apache POI that does just what we need. Yes, there is also the Ruby spreadsheet gem, but while the gem itself works fine most of the time, the underlying reverse-engineering of the BIFF8 (Excel 97-2000) format is sketchy at best. Spreadsheets generated with the spreadsheet gem don't behave as expected in Excel. For example, if you click the '%' format button, you get an error message. This ends up making our product look unpolished.
This kind of turned in to a spreadsheet gem rant, but if you step back, it's typical of a greater problem. The Ruby community is relatively small when compared with the Java community. It's also significantly less "enterprisey". This means that you'll see a lot of effort put in to things that developers like -- clever libraries, syntactic "sugar", etc -- but you're less likely to see mature libraries like Apache POI. Who the hell wants to sit around and figure out BIFF8, anyway? A lot of the enterprise stuff just isn't fun, but there are plenty of Java devs who get paid to do it for their day jobs.
That's been my experience; when testing both Mizuno (Jetty for Rack applications) and Unicorn under massively concurrent load, Unicorn tends to hit a point where it just stops responding, whereas Mizuno slows down, but handles every request successfully.
... if the original implementation had leveraged the JVM
I think that's a horrible idea. The JVM is an awful platform for any kind of language research & development, unless the type-system of that language is basically the same as in Java. I'm actually pretty upset that they've taken continuations out from 1.9 - most likely JRuby bares some blame.
Not to mention I would prefer to keep Oracle(TM) tainted stuff out of my lawn, as at this point I consider Mono/.NET to be more safe than Java.
Despite all that, JRuby does an absolutely bang-up job of working around the JVM's limitations where it can. As far as I know, it was the first language implementation anywhere on the JVM to allow forking, for instance.
True, but forking is also something which most languages running on top of Posix can do, that's not saying much.
What I really want and what is needed - a reference implementation written in 80% Ruby (or more). That's like Rubinius or Pypy, but adoption isn't great even though these virtual machines have shown better performance than the reference implementation for computational-heavy tasks.
And adoption isn't great because remarkable libraries written in native code won't run reliably or at all on top of them (e.g. Python's Scipy).
And JRuby shares the same problem, although it has the advantage of being able to use JVM-alternatives. But then you're stepping out of the Ruby ecosystem, which makes it a fork.
And to get back to "JRuby as reference implementation" ... it would be an even greater pain in the ass for alternative implementations, because C is more portable than Java.
Oh, absolutely. I'm not saying it's perfect, by any means - just that the JRuby team have pulled off an astounding job to get it as good as it is, given the limits of the JVM.
Also, native libraries are becoming less of a problem now that libffi has a bit of momentum.
This would make sense for web apps. For (presumably) many people, ruby still is mostly a sysadmin scripting language. In that case, shorter startup times are often more important than runtime performance. I personally love ruby but I wouldn't want to use it (or any dynamically typed language) for anything bigger.
I'm sure it works fine on Azul, and they've run some tests for us in the past. They've also been contributing a lot of work back to OpenJDK. It's unlikely anyone will be able to match or beat the JVMs currently available for a long time.
Project Lambda is about adding closures to the Java language. Method handles are part of the Da Vinci Machine Project (http://wikis.sun.com/display/mlvm/Home) which is at least partially supported in JDK 7.
I'm holding my breath for the RVM update for JRuby 1.6. Wayne is always on it with the updates. Can't wait to try JRuby 1.6 out. I was waiting to try JRuby until it supported 1.9.2. Looks like today is the day.
Will a stable implementation of fork() ever exist? I know JRuby provides threads, and that is great, but I have existing code that's using fork() + message-passing I don't care to rewrite it using shared memory and threads.
Have you tried it yet? Jruby will try to spawn a second independent interpreter in its own thread on the same JVM rather than actually forking an OS process if it detects that you're spawning another Ruby process. This is not without its drawbacks, but can be surprisingly handy. Your message passing code might Just Work with no alterations.
There are ways for JRuby to do an actual real live OS fork, but they aren't especially pretty.
No. The JVM spins up several threads, even when running a single-threaded Java program. Threads and fork() do not mix well together, and using threads is heavily entrenched in the Java world. I doubt Oracle intends to do the work to make fork() work.
As far as rewriting your code, would it be that difficult to change it to use threads? They don't FORCE you to share state, and there are powerful primitives for message-passing in java.util.concurrent. As long as you're not abusing global variables in Ruby it should translate over just fine.
I don't have a strong use-case for JRuby in this particular case, so I'll just continue to use YARV. There are some Java libraries I've been tempted to use, but it's not crucial at this point.
It's not implementing message passing that's the problem, it's the shared state, multi-threaded model in general. It's too easy to trip up, so I prefer fork() and message-passing. I am less worried about my own code, but what future maintainers who have less experience in concurrent programming will have to deal with.
It's just a framework for a pool of workers that hang off an MQ, so fork() also provides some extra resiliency in the event that something bad happens.
There's nothing stopping you from running multiple JRuby instances, just as you would with any other interpreter, it's just you can't use fork() to create them. Use an external script/daemon to start up multiple processes.
It's not as memory efficient as MRI, but isn't _too_ bad unless you're on a cheapo memory constrained VPS.
I personally believe the MRI core devs have done a great job of moving YARV and Ruby 1.9.x forward. We would not have added 1.9.2 support had they not cleaned it up and made it a really compelling set of features.
YARV may start to lag behind in performance measurements, but it's already faster than many popular runtimes (Python, for example) and there's nothing stopping them from making more drastic moves to improve it (adding JIT or concurrent threading).
And of course they are still the reference implementation; we want them to continue to push the boundaries of what Ruby can do, and continue to challenge us with new features.
I often think that the Ruby world would be a more productive place if the original implementation had leveraged the JVM.