Here is a digested version of an article written by Zed Shaw on pros/cons when using Ruby’s MRI and on scenarios when to leverage JRuby.
“Why is this relevant to Ruby? Recently, there’s been a huge push to take Ruby onto both the JVM and the CLR systems. Ruby’s popularity means that companies like Sun, IBM and Microsoft want to add the language (and others, such as Python) to their platforms.” -Zed Shaw
Pros for the MRI:
- Systems scripting and automation: Ruby has the added advantage in that its syntax is more impervious to obfuscation.
- Rapid prototyping and experimentation.
- Web programming: Ruby on Rails (RoR) is the latest silver bullet for Web programming. You can host Ruby on Rails applications in standard Java application servers like Tomcat, Jetty, Glassfish or Resin.
- Web application testing: Two Ruby libraries, Watir and Selenium, automate testing a site’s user interaction.
- Simplified APIs for nonexperts: Ruby’s main strength is metaprogramming. You can make little languages (domain-specific languages, or DSLs) that don’t look like Ruby.
- Gluing C APIs together: It’s trivial to take parts of a Ruby application that don’t perform well and move them to a small C library, and using a system like Ruby2C or Ruby Inline, you can do this almost on the fly.
- Prototyping network protocols: Ruby is a “good enough” language for writing simple servers and clients because of its simple threads, multiple I/O event libraries and protocol libraries for network protocols, including HTTP, SSH, SMTP and many others.
Cons for the MRI:
- Large data crunching: Ruby (all versions worth using in production, and even Ruby 1.9) suffer from huge problems with large-scale garbage collection, I/O processing and thread operations.
- Image manipulation
- Heavy math or computation
- New language development: While Ruby can build very nice DSLs, any errors in the DSL source aren’t specified in that language, but instead, as Ruby errors.
- E-mail processing: Having sendmail (and postfix) supported milter support in Python, Java, Perl and C means you can leverage an existing well-written mail server and then write your application code in nearly any language…except Ruby.
- Server protocols: With Ruby’s Threads you’ll find many problems when you try to scale your application beyond the 1,024 open files Ruby can handle.
- Breathing new life into tired old Java APIs. JRuby’s tight integration with Java libraries is so seamless that you can code against a Java API in a way that looks and feels like Ruby.
- Rapid prototyping and experimentation. JRuby lets programmers prototype and interact with Java libraries dynamically, the same way they would in a scripting language.
- Enterprise application integration: With JRuby, the parts that are best done with strict processing can be done in Java (or even just Java style), and the parts that are dirty and require
regexwizardry can be done in Ruby. You get the best of both platforms’ network libraries, string processing, file handling and design philosophies when you try to make multiple different systems talk.
- Swing or SWT GUI development: With JRuby’s metaprogramming and dynamic nature, it’s possible to build full complete professional user interfaces using SWT or Swing in a very short time.
- Enterprise deployments. The “enterprise” hates Ruby, and this is mostly a social problem.
Kind of conclusion:
“Ruby does have its problems, but I attribute most of the technical deficiencies to the MRI platform and not to the language itself.” -Zed Shaw