State of Ruby VMs: Ruby Renaissance
Ruby is commonly associated with the frameworks (Rails, RSpec, and many others) that it enabled, but it is much more than that. The same ideology and design principles that popularized the language at the start are also the reason why it is being currently ported to a variety of alternative platforms: JVM, Objective-C, Smalltalk VM and Microsoft’s DLR. Technical details aside, few will disagree that Matz’s focus on “how we feel while programming” and the objective of “making the programmer happy” has resonated with the larger community.
In a short span of just a couple of years, the Ruby VM space has evolved to more than just a handful of choices: MRI, JRuby, IronRuby, MacRuby, Rubinius, MagLev, REE and BlueRuby. In fact, keeping up with all of the most recent developments within each VM is now easily a full-time job. For that reason, and with RubyConf ‘09 in full swing, let’s take a quick survey of the space and where it’s taking us.
2010: Year of Ruby Renaissance
Observing the trends and acceleration of development amongst all the VM’s, it is clear that 2010 is going to be an exciting year for the language. While more than a few developers have proclaimed Ruby (and more often, Rails) as dead within the past year, likely due to it losing the initial novelty angle, in reality the language is at the cusp of becoming available to a much broader community. Within the next year, MacRuby, Rubinius, IronRuby, and MagLev should all hit the 1.0 status, effectively making all the things we love about Ruby available to entirely new communities of programmers. HotCocoa with MacRuby makes writing Mac apps a breeze, IronRuby will bring Ruby scripting to the .NET crowd, Rubinius will become a viable deployment platform, and MagLev will give us the distributed persistence model offered by their Smalltalk VM. All of this without even mentioning the growing adoption of JRuby, which marries the best of JVM with Ruby, or the rising popularity of REE fork of Matz’s Ruby which offers significant performance and memory improvements.
In other words, if the “Ruby revolution is over”, then the next year is likely to be the first year of its Renaissance. It won’t happen overnight, but slowly and surely we will see the same idioms, tools, and DSL’s we are all accustomed to in Ruby make their way to adjacent platforms. Many projects and companies are already using RSpec and WebRat to test their non-Ruby code. Likewise, why not use Ruby for DOM manipulation via Silverlight (Gestalt), or abstract Java or Cocoa API’s into concise DSL’s? It’s an exciting time to be a Rubyist.
MRI: Matz’s Ruby (1.8.x / 1.9.x)
MRI Ruby, which is the original and the default platform for the vast majority of Ruby users have been making steady progress throughout the past year. First, we saw the 1.9.1 release at the beginning of the year, which made Ruby 1.9 a viable deployment platform, although the overall pickup has remained relatively low. In mid July, Ruby 1.9.2 preview 1 hit the shelves, and the original schedule planned for the final 1.9.2 release on December 25th. However, Yuki Sonoda (release manager) recently indicated that the schedule will be canceled in favor of making Ruby 1.9.2 compatible with the RubySpec suite prior to the final release - this is great news for everyone and well worth the wait.
Sitting in the audience at RubyKaigi in Tokyo earlier this year, it was clear that the focus of the development team is on Ruby 1.9. Moving forward, there will be one more release within the 1.8.x branch (Ruby 1.8.8), and it will serve as a bridge between 1.8 and 1.9. If you haven’t already, you should investigate migrating your code to Ruby 1.9 - most of the critical gems, and all popular frameworks work out of the box, not to mention the numerous performance improvements.
In the coming year, we may even see a Ruby 2.0, and in all likelihood a continual improvement in speed and library support. Matz showed off a number of experimental branches at RubyKaigi, and Koichi Sasada indicated that many of the performance optimizations are yet to be turned on for Ruby 1.9 - to date the focus has been on compatibility and feature completeness.
JRuby: Ruby on the JVM
Out of all the “alternative” Ruby VM’s, JRuby is by far the most mature project both in terms of compatibility and community coverage. By combining the best of the JVM platform - generational GC, true concurrency (no GIL), and transparent interop with any Java library - with Ruby syntax, it is no surprise that JRuby has been quietly gaining market share in the community. It is fast, it runs Rails, and it will soon be compatible with Ruby 1.9.
Within the past year the JRuby team, which consists of 7 active committers (3 of whom migrated from Sun to Engine Yard earlier this year) , and dozens of intermittent contributors has fixed more user reported issues than in all previous releases combined. JRuby 1.4.0 is a good indicator of the health of the project: a large collection of new features, and over 307 bug fixes since JRuby 1.3.1.
Tickets for JRubyConf were sold out in a matter of hours following the announcement, and in all likelihood serve as a good indicator that JRuby is the platform to watch in the coming year. The combination of the JVM optimizations and its widescale deployment within the enterprise world will definitely make it an appealing Ruby VM.
MacRuby: Objective-C, LLVM and Ruby
Want to mix and match Cocoa API’s or access OSX system libraries all within a Ruby VM? Then MacRuby is the answer and the VM is picking up steam fast. On March 9th, MacRuby 0.4 shipped with a threaded GC, full 64-bit support, DTrace probes, and many improvements to the HotCocoa API’s. Since then, the project has switched from YARV to a completely new VM based on LLVM compiler infrastructure (shipped in 0.5 beta 1), and the benefits are numerous: machine code compilation, true concurrency (no GIL), a working JIT, and even ahead of time compilation (AOT)!
In other words, MacRuby is now a true Ruby compiler. You can write a HotCocoa app, leverage native POSIX threads, or even take advantage of Apple’s Grand Central Dispatch (GCD) and then compile your program and distribute it as a binary to any OSX user.
With 7 members on the team and a growing community (RubyOnOSX), MacRuby is quickly becoming one of the most promising open-source projects for Apple - it would be great to see them officially embrace it in the coming year. With the new VM and numerous performance improvements, MacRuby has the potential to bring Ruby to all the Objective-C developers and open up an entirely new market for Ruby. In theory, we could even see MacRuby on the IPhone, that is, if we overcome a few minor snags, like a missing GC. Definitely a project to watch in the coming year as it edges towards the 1.0 status.
MagLev: Smalltalk VM and Ruby
The GemStone team has been quietly making steady progress with MagLev over the past year. The development is being done in parallel with work on their upcoming GemStone 3.0 VM and is promising to bring Ruby to their 64-bit Smalltalk VM, which offers a JIT, years of VM optimizations, and most importantly, a built-in persistence and distribution layer. In other words, you could think of Maglev as a distributed database that runs Ruby code internally - thousands of concurrent VM’s can be spread across hundreds of nodes, all accessing the same data with ACID semantics.
At RailsConf this year the team showed off a working Sinatra app, and since then they have gone from passing 5000 to nearly ~27900 RubySpecs. Rack, Sinatra, MiniTest and a few others already run unmodified on the VM and the tentative plan is for the project to hit 1.0 sometime in the upcoming year. At the moment, there is a closed alpha test in progress, but soon it will be opened to the larger public. (Update: grab the public beta here).
The persistence layer offered by the VM is definitely one of the most interesting features, but the team has also indicated that MagLev will support other persistence models as well - you’ll be able to use ActiveRecord with MySQL, etc.
Ruby Enterprise Edition
Launched in mid 2008, REE is a fork of Ruby 1.8.7 optimized for server and production deployments of MRI Ruby. Combination of MBARI patches, improvements in thread and scheduling overhead by Joe Damato and Aman Gupta, a copy-on-write (COW) fork model, and a tunable GC all contribute to a measurable difference in the amount of used memory and overall performance. Earlier this year Twitter switched their infrastructure to REE and reported a 30% improvement in throughput!
Phusion Passenger, developed by the same team, has also seen a good pickup in the community within the past year, but it remains to be seen if REE adoption will continue to grow in light of all the progress by alternative VM’s.
IronRuby: Ruby on .NET
IronRuby is a .NET implementation of the Ruby VM which leverages Microsoft’s Dynamic Language Runtime (DLR), and hence enables an entire host of interesting use cases for Ruby. For example, not only is there seamless integration with all the .NET libraries and infrastructure, but running on top of the DLR also means that Ruby can be run within Silverlight (yep, right in your browser - check out Gestalt).
The 1.0 release is looming on the horizon and the team has been making great progress. IronRuby now passes over 92% of all the RubySpecs and the adaptive compiler, combined with the optimized DLR also means much lower VM startup times, as well as significant performance improvements over MRI. (Update: download IronRuby 1.0 RC1)
It remains to be seen if the .NET community will embrace IronRuby, but it sounds like tool support (Visual Studio, Intellisense, etc) might be the next big hurdle for the project.
Rubinius: Ruby written in (mostly) Ruby
Rubinius is an initiative to implement as much of Ruby as possible via Ruby code itself - turtles all the way down. In the works since 2006, the Rubinius team lost a few developers early this year, but the project is alive and healthy. The VM has been rewritten in C++, a JIT compiler has been added, and you can now run mongrel, thin, rack, amqp, and a number of other gems all unmodified. The roadmap shows 1.0RC in the works, and a focus on enabling real-world application deployments (packaging, distribution, etc).
It is too early to talk about performance, but the combination of the JIT and LLVM infrastructure means that Rubinius will have true concurrency (no GIL), and plenty of opportunities for introspection and optimization of your code - an inherent benefit of rewriting Ruby in Ruby itself.
Both FFI and RubySpecs, which are now used by virtually every other VM are a direct result of the project, so all things considered, Rubinius can already be called a resounding success. However, with 1.0 on the horizon, it remains to be seen how and if the community will react to the release. Getting a few production deployments under the belt, as well as building a larger user community, are likely to be the big challenges for the year ahead.
BlueRuby: Ruby on ABAP VM
An exploratory research project form SAP Labs, BlueRuby is an initiative to bring the Ruby runtime to the ABAP VM powering the AP NetWeaver and SAP ERP 6.0 products. It is already passing 75.5% of all the RubySpecs and is being pushed by SAP as a way to adopt TDD practices within their products. At this point, there is no known release schedule or public roadmap for BlueRuby, so don’t expect Rails apps on top of SAP NetWeaver anytime soon, but it does have the potential to bring Ruby and all the best practices enabled by it to thousands of enterprise developers.
Rubies everywhere!
Talking to the developers of all of the alternative VM's you can't help but to feel excited about the future of Ruby. There is a clear pattern emerging: using Ruby to go beyond Ruby, and as a bridge to other communities. Halfway through RubyConf, it is a clear theme here as well - several serialization talks, code generation, and an entire evening of presentations on all the Ruby VM's.
Ilya Grigorik is a web ecosystem engineer, author of High Performance Browser Networking (O'Reilly), and Principal Engineer at Shopify — follow on Twitter.