Rubinius is a Ruby implementation written in Ruby and C++ that aims to compete with MRI by coming with a modern GC implementation, a powerful JIT (using LLVM) and tools like fast debuggers and profilers.
Rubinius, currently at version 1.2.x, has recently reached another maturity milestone: EngineYard offers Rubinius as one of the Ruby runtimes of choice on its AppCloud.
InfoQ talked to EngineYard's Evan Phoenix, the original creator and longtime developer of Rubinius, about the present and future of Rubinius.
InfoQ: What's AppCloud & the Beta program? Can users use Rubinius in production?
This means that users are free to use Rubinius however they'd within AppCloud, but that we're looking for feedback and bug reports on the system. Once we get satisfactory feedback and users are reporting that the system is running great for them, we'll move it to general availability.
So users can certainly use it in production, but they may hit bugs. :)
InfoQ: How does the AppCloud setup exploit the available CPUs or cores? Is it necessary to run multiple Rubinius instances? Is there some sharing possible across Rubinius instances (a la REE)?
Rubinius integrates with the system in the same way REE, namely with passenger and unicorn. This launching of several processes does allow for multiple core usage, but unlike REE, Rubinius is not optimized for any kind of memory sharing between process. This is because the technology in the GC, specifically the ability to move objects, is not sharing friendly. But this improved GC technology also means that the process has much tighter control over the amount of memory it has requested from the OS, so Rubinius processes should not see the unbounded memory usage issues that MRI and REE can have.
InfoQ: What's the status of the 1.9 support and GIL (Global Interpreter Lock) slaying effort in the Hydra branch?
Both efforts are ongoing in the hydra branch. We've recently changed the version number of the hydra branch to 2.0 to reflect that it is truly the future of Rubinius. We're aiming to have 2.0 out this summer as well. This optimistic timeframe reflects the status of these features. The GIL removal has gone amazingly well and the hydra branch has quite stable. Brian [Ford] has been hard at work getting a 1.9 parser up and running and once that happens, the 1.9 changes should begin to flow quickly.
InfoQ: What told you that Rubinius is mature/complete enough for AppCloud? Are there other performance tools, besides the profiler & heap analysis tool, that you'd like to mention?
We knew Rubinius was mature enough because users started telling me so. We didn't know it, but a while ago we hit some kind of compatibility threshold where the vast majority of the code in the wild just worked. We still have compatibility related bugs here and there, but by and large it seems to have plateaued. There are definitely still performance bugs in the system that we're actively working on also, but again it seems to have hit a point where it works well enough for the majority of the work people want it to do.
Tooling wise, people continue to discover the great things we've built right into Rubinius. The profiler continues to be an element that we improve and users love giving us feedback about how well it helps them optimize their code.
We've only begun to scratch the surface of what's available with the heap analysis tools and users are already reporting how much it helps them figure out issues with their apps. Feedback, both good and bad, is what fuels us to improve the tools to make users lives easier.
To check that a Gem is compatible with Rubinius, isitrubinius.com is the place to look for information and user experiences.
Rubinius is available using rvm or from the Rubinius website.