Tag: ruby

Rubinius is an implementation of the Ruby language spec. I’ve been using it recently for a project, and I’ve been liking it so far. Here’s a few thoughts I’ve been having while using it.

Philosophy

The Core

Rubinius, in its core, is written in C++ and uses LLVM (Low Level Virtual Machine). Without getting too technical, it translates the Ruby code that you write into efficient machine code, then executes the machine code directly on the CPU. This architecture is very similar to Google’s V8 (and one of the reasons that Google Chrome is a fast browser).

The Concept

Now for the concept of “Ruby”. “Ruby” is a programming language specification, not a program or compiler. The standard reference implementation is called MRI (Matz’s Ruby Interpreter, not magnetic resonance imaging). MRI is used in many production environments, and especially with the latest 2.0.0 release, introduces many performance improvements, and is very stable (all of our new Rails apps are on 2.0.0).

MRI is written mostly in C.

Rubinius’ tagline “Rubinius: Use Ruby™” summarizes the intent of Rubinius. Use Ruby! Because the Rubinius core is as fast as it is, and Ruby code is basically machine code (from the computer’s standpoint), standard libraries – the basic functions of the language – can be written in Ruby. Use Ruby!!

Speed

In development, Rubinius seems to be a little slower than MRI – especially in the first load. Rails is a big library.

In production, especially with a threaded app server (Rubinius has no “Global Interpreter Lock” and supports real threads), however, Rubinius is extremely fast. I’ve been using Puma.

You do need to write thread-safe code, but the payoffs are enormous.

Conclusion

This little project I’m working on will probably not see a “real production” environment anytime soon, so I really wanted to try out some alternative Rubies (there are a few). All in all, my experience with Rubinius has been very good. Can’t wait for the production release of Rubinius!