JRuby 1.6.0.RC1 Released | Hacker News Reader

JRuby 1.6.0.RC1 Released

jruby.org

21 pointsfranze19 comments

It's speedy. It's empowering. But it's (stil?) a memory hog. My personal issue with it is the memory consumption. Other than that it's an amazing project.

Initially, it will use more memory. But for a longer-running, large application, we usually come out ahead.

We also set the JVM up to a fairly high maximum heap (500MB) which you can tweak back down a la -J-Xmx200M.

> Over 2000 commits

I fail to see how this is a major feature. Maybe it fulfills an enterprise requirement?

It's an OK metric for project activity.

Why on earth would you choose a Java version of Ruby over a C version of Ruby? It seems to me people only use JRuby if they have a requirement for both Java and Ruby projects...J2EE developers?

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.

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.

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.

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

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.

Why would you not?

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...

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)

Reply on news.ycombinator.com