It's faster than MRI. It allows you to write Java instead of C extensions. For developers without a C background, but with a Java or c# background that's pretty huge IMO.

Plus instead of running 16 Unicorn workers for an app, eating up over 4GB of memory, I can run one JRuby thread-pooled app, handling many more connections gracefully, with lower memory requirements, fewer database connections and better performance.

My personal experience was that after trying to set up a connection to Sql Server 2000 for 2 days I tried to access via JRuby and had everything working in minutes.

Very pleasant surprise indeed.

I had exactly the same experience while trying to cook up an ad hoc test utility at our startup. I spent two days bumbling around with MRI Ruby and various gems and C libraries -- two days of utter frustration. I eventually realized that I could easily talk to any database with a JDBC library if I switched to JRuby, and that's what I did. Like you, I was up and running in minutes.

Because:

You get the whole Java ecosystem at your fingers. It's faster than MRI (1.8.7ish) and a contender (maybe even faster now) against MRI 1.9.2. It interops with other JVM languages. It plays nicely with uptight IT departments (you only need to download the jars).

The 1.9.2 interpreter is YARV, not MRI: http://en.wikipedia.org/wiki/YARV

YARV is the VM, it's still MRI (Matz's Ruby Interpreter)

Not that I've ever seen referenced. You don't really see the YARV name thrown a ton these days either I guess, but MRI means C-Ruby to most I think. YARV is a VM and from what I understand Matz had very little to do with it in the period leading up to 1.9.

Maybe it was behind the scenes, but the original status pages for YARV gave the impression it was a one man job up until it was official.

Access the many Java libraries available, it's the only Ruby interpretor with true threading (no GIL), integrates in the Java server ecosystem ( say with servlets via java-rack etc), upstream IT management approval (it's enterprise).

Interestingly, because it has true threading, it's actually harder to debug threading problems with JRuby than it is with MRI. MRI will tell you precisely where a deadlock happens, where JRuby just locks up. So it's good to have both.

I can't claim this with authority, but I would imagine that in most cases you would get better garbage collection performance from a JVM than from the MRI runtime, as the various JVMs have almost certainly been subjected to a greater amount of attention and work.

Perhaps for access to the large and mature standard Java class library or access to other libraries written for Java?

For instance you can get real concurrency. Example: using a Scala framework called Akka, you can easily set up local map-reduces tasks, which trivially speeds up computation: http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-l...

Why would you not?

I've heard of at least a few rails deploys where the dev environment is MRI, for fast CI / test suite runs, and production is JRuby, for all the other (numerous) benefits listed here.

(Although i can't google any examples in print)