JRuby 1.6.0.RC1 Released(jruby.org)
jruby.org
JRuby 1.6.0.RC1 Released
http://www.jruby.org/2011/01/10/jruby-1-6-0-rc1
3 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.
We also set the JVM up to a fairly high maximum heap (500MB) which you can tweak back down a la -J-Xmx200M.
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.
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.
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).
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.
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)
(Although i can't google any examples in print)