Although Ruby 2.1 hasn’t been released yet, the just release Rubinus Ruby runtime’s version 2.0 is aiming towards being Ruby 2.1 compatible. Rubinus, for those who don’t know of it, is an implementation of Ruby which uses an LLVM JIT compiler, generational garbage collector and native threads to give a Ruby runtime that can run efficiently on all CPU cores of a modern platform. The developers are also maintainers of RubySpec, a 20,000 plus strong library of specifications which map MRI (Matz’s Ruby Implementation), created to assist maintain compatibility with the ‘reference’ Ruby implementation; RubySpec is now used by many other Ruby implementations to ensure compatibility.
As the developers explain while the Ruby 2.1 MRI runtime hasn’t been released yet, they are aiming to improve compatibility with the leading edge of Ruby. This comes with a sacrifice though; historically the Rubinus developers have tried to support multiple Ruby versions and all the oddness that happens in any system where the specification is the implementation. The developers hope that this change, along with a focus on creating concurrent distributed applications, will make “Ruby competitive with Go, Erlang, Clojure, Scala and Node” in that domain. This means, they say, performance and stability of that kind of application will be prioritised over supporting some legacy Ruby code or “quirky Ruby feature”. In preparation for a more componentised Ruby, Rubinus 2.0 has isolated the standard library into a Ruby gem. There’s also a new release system for the Rubunius platform with a new versioning scheme being introduced in the transition between 2.0 and 3.0.
The developers also outline their own future thoughts and plans for Rubinus, including better (and less) concurrency coordination, less finely grained locks replacing the Ruby GIL, a more concurrent and parallel garbage collector and a more Ruby semantics informed JIT. The plans set out are focussed on making sure Ruby isn’t left behind in the new slew of languages and as the Rubinus team say “developers who are happy writing Ruby shouldn’t be forced to leave it because of technical limitations” – limitations they are setting out to remove.
This article was imported from the original CodeScaling blog