Mitchell Hashimoto

Welcome to Ruby. We Have Many Rubies.

Although I consider myself (and I’m proud to be) a polyglot, most of my open source code is Ruby. I’ve been a Rubyist for almost 5 years now and it is still my language of choice for starting projects. Professionally, I’ve begun to use Python in the work-place, and in the process of learning Python I’ve had a hard time understanding the various Python implementations. Additionally, I know friends coming to Ruby who have trouble understanding the reasoning behind all the different Ruby implementations.

As such, I’m going to give a brief overview of the major Rubies available, their purpose, their development status, and my opinion of them. I’ll cover Matz’s Ruby (MRI or CRuby), Ruby Enterprise Edition (REE), JRuby, Rubinius (rbx), MacRuby, IronRuby, and MagLev.

The world of Rubies is unlike other languages, such as Python, where I would guess 95%+ use CPython exclusively. It is not uncommon for a single Ruby developer to use Rubinius at home, JRuby for production deployment, and MacRuby for desktop development.

Matz’s Ruby Interpreter

Matz’s Ruby interpreter, or more commonly called MRI, is the original Ruby interpreter. This is the one you get by default from the official Ruby website or the one you probably get if you install Ruby via your package manager.

MRI is also where all the new Ruby features land first, and as such is currently the place where Ruby moves forward. Other implementations strive to reach compatibility with all Ruby that works with MRI.

Technical detail: You may see some people reference “YARV.” YARV is the Ruby VM powering Ruby 1.9, and stands for “Yet Another Ruby VM.” YARV technically replaced MRI (which powered 1.8), although Ruby 1.9 is still known as MRI.

My opinion: MRI is still the most mainstream Ruby. It is maintained by the Ruby-dev team and when someone is a “Ruby programmer” they’re usually referring to this Ruby. I personally still run this Ruby as my default at home.

Ruby Enterprise Edition

Ruby Enterprise Edition (or REE for short) is a fork of MRI (Ruby 1.8) which adds some optimizations which make running Ruby in production more performant. Some of the optimizations it adds:

• Copy-on-write friendly garbage collector, which makes forking much less expensive.
• Improved memory allocator
• Tunable GC settings, important for servers!

My opinion: I don’t have a lot of experience with REE. Many people, such as Twitter, use it in production with great success. I’ve heard nothing but good things about it, but prefer JRuby for deployment myself.

JRuby

JRuby is a complete Ruby implementation written in Java on top of the JVM, which provides complete interaction with Java libraries.

For those new to the concept of additional languages on top of the JVM, this may seem like a huge “why?” The JVM is mature, battle-tested, and exceptionally performant. The Java ecosystem is filled with every library imaginable and is the de facto enterprise language. By putting Ruby on top of the JVM you gain numerous benefits:

• Portability and speed of the JVM
• Every Java library becomes a Ruby library

My opinion: JRuby is amazing. It can even compile most MRI C extensions (think about that for a moment). Also, I’ve found deploying web applications as war files the easiest method for deployment available. JRuby also beats MRI in many benchmarks. Its fast!

Rubinius

Rubinius is a new virtual machine build from the ground up for Ruby. It is written in C++ and can JIT Ruby code to LLVM bytecode. Rubinius can execute Ruby fast, far faster than MRI. The performance hits to Rubinius come from C extensions, which are slower than MRI.

Brian Ford, one of the developers behind Rubinius, posted a good Why Use Rubinius? article that is worth reading.

My opinion: Rubinius is clearly the future of Ruby VMs. The C++ implementation is beautiful and extensible, whereas the MRI code base is a mess of spaghetti C. Rubinius is extremely performant, and there are a lot of forward-thinking ideas within the VM itself. Rubinius runs most Ruby code, but still hasn’t replaced MRI for me as my default Ruby for edge-case reasons. I recommend giving Rubinius a shot if you havent.

MacRuby

MacRuby is a fork of Ruby 1.9 made by Apple, Inc. MacRuby compiles to LLVM bytecode and can interface with all of Cocoa. MacRuby can even do things like Grand Central Dispatch elegantly.

The point of MacRuby is to allow building Mac applications with a Ruby that is deeply integrated with Mac, such that performance doesn’t suffer and resulting applications are truly native.

Cool use case: Twitter uses MacRuby to unit test much of their Cocoa libraries that their iOS and Mac native clients use. This makes sense thanks to Ruby’s beautiful test libraries.

My opinion: If you’re making a Mac app, you should really use MacRuby. You can punt the super high-performance stuff to Objective-C and have MacRuby interface with it. Its a no-brainer if you’re a Ruby developer looking to make a Mac app.

IronRuby

This is here for completions sake. IronRuby is Ruby on top of the .NET runtime. This is exactly analogous to JRuby and the JVM.

MagLev

MagLev is built by GemStone and it is Ruby on top of a smalltalk virtual machine. It has a JIT as well as an impressive built-in persistence system across multiple VMs.

My opinion: I’m not aware of any people using MagLev in production personally, but its certainly worth watching.

Playing with Rubies

Want to play with other Rubies easily? Just use the Ruby Version Manager (or rvm for short) which makes it dead simple to install multiple Ruby versions and implementations side by side.

Now, can someone make one of these posts for Python? Thanks!