The Rubinius team just announced the release of Rubinius 2.0. The last released version of Rubinius (1.2.4) is more than two years old and supported Ruby 1.8.7. Since then, Ruby 1.8 has been deprecated and Ruby developers are urged to update from 1.9 to 2.0.
Rubinius 2.0 plans to fully support the upcoming Ruby version 2.1. From the release announcement:
With the 2.0 release, Rubinius regains a laser focus on supporting the future of Ruby. Rubinius 2.0 is expected to be compatible with Ruby 2.1. While MRI hasn't released 2.1 yet, Rubinius will continue improving compatibility as more features are finalized.
Going forward, the release cycle of Rubinius will accelerate a lot. New versions are planned to be released weekly:
We're moving to this release process to get updates into your hands as quickly as possible. No matter how much work we do, there is always more. A release never seems ready. Releases are painful to get right. So we are following the advice, "If something is painful, push it to the front and work to reduce the pain." There will be bugs with our Ruby 2.1 compatibility. [..]
The goal is to semantically version the Rubinius core starting with version 3.0. During the 2.x to 3.0 transition, we'll be very careful about introducing breaking changes, but we'll do so when the benefits outweigh the risks.
Rubinius 2.0 made a lot of progress in its multi threading support. Rubinius comes with a virtual machine to run the byte code produced by the compiler and also implements a just in time (JIT) compiler to get even more speed (2-4 times speed-up at the moment, but they expect to boost this further). Because Rubinius isn't constrained by a global interpreter lock (GIL) and implements native threads, Ruby code can utilize multiple cores and CPUs. This also benefits the garbage collector that can run partially in parallel with the executing code. Rubinius' Brian Shirai elaborates on this in a lot more detail in an interview by Jesse Storimer.
InfoQ had the chance to talk to Brian about the new release. Rubinius 2.0 promises Ruby 2.1 compatibility, which hasn't been finalized yet. What of Ruby 2.1 have you already implemented?
We're trying to track MRI development leading up to the MRI 2.1 release. The MRI team has repeatedly promised substantial backward compatibility for both 2.0 and 2.1. We pass tons of 2.0 specs, which basically means that 2.0 behavior hasn't diverged much from 1.9, but there are a number of cases where behavior changed.
Short answer is we intend to support as much of 2.1 as we can when 2.1 is released. In the meantime, or if there are serious conflicts, we'll continue with the 2.0 behavior until 2.1 is released.
InfoQ: Does Rubinius 2.0 support Windows?
Windows support is definitely on the list of things we want. However, we'll have to see if anyone wants it bad enough that we devote scarce resources to it.
InfoQ: How well do existing applications and frameworks work with Rubinius? For example, does Rails 4 run on Rubinius?
Rails 4 famously said that it "prefers" Ruby 2.0. We expect Rails 4 to run on Rubinius. If it doesn't, it's likely a bug in Rubinius (but may be a bug in Rails).
Rubinius 2.0 is available on rubini.us. We'd love to hear your experience with it!
