It seems to be all going on with the developers of Rubinus, the LLVM JIT-powered Ruby implementation which recently hit version 2.0.0. First came the news that Engine Yard had ended their sponsorship for the project saying that “we no longer feel like the project needs any help from us to accelerate” - the ending of sponsorship will, they say, let them invest more in other emerging projects.
With that announcement made, Rubinus lead Brian Shirai said “I have been working to simplify and focus the project”; funding changes do tend to allow projects to step back and look at their goals. In this case, the results of that work turned up in an announcement of Rubinus X.
Rubinus X is billed as an experiment in modernising Ruby, which the project’s home page declares as no longer relevant to modern computing. The plan appears to be a major reworking of Ruby - concurrency with Promises and non-blocking I/O, persistent data structures, object composition, code loading as an API, consistency through composing operations from system primitives, immutable strings and a more explicit OO model. There is also a clean up of the language planned with a single encoding used within running programs, the removal of position-significant arguments in API calls, a defined numeric tower and the purging of Perl-inspired features and global variables.
Shirai declared “Ruby is a dying language” which triggered much discussion over on sites like Hacker News about whether Ruby was dying or not and whether Node.js was the new Ruby/Rails but very little conversation on the merits of the Rubinus X plan. More details on how the Rubinus X project will develop will be disclosed in the coming days via the mailing list (which has already got 570 signups). Rubinus X does seem to have some ambitious goals and with the development taking place outside the mainstream of Ruby, it shouldn’t have an impact on Ruby development at least until it has proven itself. What affect it will have on Rubinus development is unclear though; with no one paid to develop it, resources will be tight. Definitely one to keep an eye on.
This article was imported from the original CodeScaling blog