5 ms·
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
by acconrad 16y ago
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?
- ssmoot 16y agoIt'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.
- sad 16y agoBecause: 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).
- epochwolf 16y agoThe 1.9.2 interpreter is YARV, not MRI: http://en.wikipedia.org/wiki/YARV http://en.wikipedia.org/wiki/YARV
- sad 16y agoYARV is the VM, it's still MRI (Matz's Ruby Interpreter)
- ssmoot 16y agoNot 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.
- famoreira 16y agoMy 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.
- cobralibre 16y agoI 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.
- kazoolist 16y agoPerhaps for access to the large and mature standard Java class library or access to other libraries written for Java?
- clyfe 16y agoAccess 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).
- regularfry 16y agoInterestingly, 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.
- cobralibre 16y agoI 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.
- regularfry 16y agoWhy would you not?
- DanielRibeiro 16y agoFor 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-level-concurrency-with-jruby-and-akka-actors/ http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-l...
- gtani 16y agoI'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)