The long-awaited release of Rubinius 1.0 has finally arrived. It has been over 3-1/2 years in the making but this Ruby implementation written in Ruby is here and offers some promising features.
Rubinius 1.0 touts many features for Ruby developers, including:
- Supports a huge amount of Ruby code and popular C extensions:
- Rails 3 and 2.3.5
- Sinatra
- sqlite3, mysql, nokogiri, yajl-ruby
- Much, much more!
- JIT compiler to accelerate running Ruby code.
- Generational Garbage Collector.
- Integrated profiler.
We have covered Rubinius in the past, including an interview with Evan Phoenix from RubyConf 2009 explaining the status of the project at the time. We also wrote about an interesting perspective of Ruby standards which included Brian Ford as he explains how Rubinius is all about standards. Fast forward to today and we catch up with Brian Ford and Evan Phoenix to talk about Rubinius 1.0 and its future.
Now that Rubinius 1.0 is out, we wanted to know what this release means today for the implementation and its future:
1.0 is really the culmination of the last nearly 4 years worth of work. We've developed an Ruby runtime that is 1.8.7 compatible that uses a lot of the latest research in making dynamic languages fast. These include things like a generational garbage collector and an integrated JIT compiler.
Because our approach was to write as much in Ruby as we can, what we're currently missing is performance in a few methods. This is because where as Rubinius is running ruby to implement the method, MRI is running C. As we improve the performance of the method and the system overall, what you're seeing is ruby code compete with C code in terms of performance.
On the subject of compatibility with existing Ruby frameworks:
Fully compatible. There was a quirky bug running a Sinatra app in a certain way in 1.0 that we've already addressed. As users hit bugs running any of these frameworks under Rubinius, we're right on top of them, getting them in the next bugfix release.
When asked how well Rubinius supports existing Ruby gems:
If the Ruby is pure-Ruby, it works no problem. We also support a large number of gems that have C extensions such as Nokogiri, Mongrel, and many more. There are certain constructs we don't support and we've been working with extension writers to try and phase those constructs out in favor of APIs we can support. The reason we can't support certain things is that API directly exposes the memory of the internal structures MRI uses to implement a class. For instance, RHASH() allows you to access an 'st' structure pointer, which is the raw C structure MRI uses to implement Hash. We don't use st to implement hash, so we have no way to provide this. Instead we've written APIs that provide the same functionality in a way we can implement.
We heard the aspect of strings being slower in Rubinius and since strings are a large part of most Ruby applications, we wanted to know what we could expect using Rubinius today and how it would be addressed in the future:
It's inaccurate to say that all of string is slower than 1.8.x. The majority of String methods are the same speed or faster than 1.8. Just a handful are currently slower, such as tr, gsub, and unpack. We're actively working on bringing these up to speed.
The topic of performance is always of interest, when asked how Rubinius stood up to other Ruby implementations such as MRI 1.8.x/1.9.x and MacRuby:
Rubinius is extremely fast at running Ruby code, so if the benchmark is a pure ruby algorithm, Rubinius is at right at the top. Because of our JIT technology, we can offer performance higher than MacRuby as well because we can take advantage of profiled information to generate faster machine code.
Where users will see Rubinius slower is hitting a some core class methods. I invite users to open issues about slowness they see in our issue tracker and ask about it in #rubinius. Every release should narrow the gap and eventually push Rubinius over the top with all core methods in terms of performance compared to 1.8.
Rubinius is an open source project and open source projects reply on the community to become successful and grown. Discussing how the community could best help this project:
We pride ourselves on making the code base approachable, making it easy to enhance and hack on. Because we use Ruby itself to implement a lot of the system, we can quickly write and debug functionality, providing users with new features and fixes fast.
The biggest thing the community could do now is try to run their code under Rubinius and report their successes and failures. This will help us grow and address any shortcomings we have.
On the subject of what we can expect next, both near term and longer term:
We're already planning for the next bugfix and feature release. 1.0.1 will likely be out next week (the week of May 24th) and will continue a number of bugfixes found in 1.0 by new users.
One of our high priority items for the first feature release, 1.1, is the debugger. I've been actively working on this and it's coming along nicely. I think that users will really enjoy the tight integration with the debugger and the rest of the system.
Rubinius does have a rubinius-dev list on Google where developers can get involved and ask questions.
More information about Rubinius 1.0 can be found on the Rubinius web site and the source code can be pulled from the project’s Github repository.