Rubinius 2.0 release

Today on the official website of the Rubinius project there was great news about the release of version 2.0 and the plans for the project for the future. Rubinius is an alternative implementation of the executable environment for the Ruby language, along with the official MRI, JRuby, and other less well-known developments.

Release 2.0 is considered compatible with the not yet released Ruby 2.1 specification, and will be further modified by new versions as new functionality is consolidated in the MRI. Ruby is moving forward, and all its users should follow it. This is what the main man in the Ruby world, Matz, calls for. If you are still at 1.9 - switch to 2.0 as soon as possible, Ruby developers have tried very hard to make the transition to it minimally time consuming and painful. The goal of the Rubinius project is also to improve the technology of the interpreter so that it would be possible to create applications and services that are faster, more stable and more efficiently use computer power. Previously, the project was known for its rigor in implementing all aspects of the Ruby language, but now this approach to development is incompatible with the new concept of development. Starting with version 2.0, the Rubinius team will concentrate on parallel and distributed computing. Because of this, not every existing code will work on Rubinius, which is trying to make Go, Erlang, Clojure, Scala and Node competitors from Ruby.

Also, starting with version 2.0, the cycle and numbering of project releases is changed. It is expected that new versions will be released once a week or so. As before, the “master” branch will contain the most stable code. If the new release turns out to be a minor, correcting error, then its version number will increase by one in the third position (XYZ -> XYZ + 1), and if the change is related to the new functionality, then in the second (XYZ -> X.Y + 1.0 ). This is due to the fact that, as such, the final release will not be anyway, this is not the product. There will always be bugs, something added to the library or the kernel, and the team will always have quite a lot of work. By version 3.0, the project plans to move to semantic numbering , but for now everything will be done during the 2nd branch to ensure a painless transition.
')
In addition, the site http://releases.rubini.us is now launched, which will store tarballs with releases and provide access to them via the API. Within a few days, all Ruby installers (RVM, rbenv, and others) should go to work with this particular API.

Rubinius components

Many have heard that Rubinius is another implementation of the Ruby programming language. However, this definition hides many details. Now we will briefly review the technologies used in Rubinius and plans for their improvement.

The Rubinius architecture is standard among modern executable environments for various programming languages.

The virtual machine executes the bytecode generated by the Ruby compiler. It is worth noting that every method in Ruby has its own interpreter. This allows you to implement many useful things, for example, the built-in debugger. Only one of the Ruby methods with specific breakpoints uses the debug interpreter.

The generic garbage collector is fairly fast, usually for assembly it stops execution less than 15 ms. Applications running in Rubinius usually work with even shorter and more rare delays, since the entire heap must be rarely cleared. Rubinius also uses a partially parallel method of marking the objects to be deleted, which further reduces the time delays during full cleaning.

Rubinius works with real system threads and does not have a global interpreter lock (GIL). On multiprocessor and multi-core machines, Ruby code runs in parallel.

The Rubinius Dynamic (JIT) compiler converts Ruby bytecode to machine code. The thread in which the JIT compiler runs is virtually independent of other Ruby threads, so its operation does not affect the performance of the application. The real-time JIT compiler keeps track of the most frequently called methods and used object types and using this information, it can combine the methods of the application and the standard library, generating well-optimized machine code that is executed several times faster than the Ruby-bytecode interpreter does.

The standard Rubinius libraries (for example, Array, Hash, Range ...), as well as all supporting tools (bytecode compiler, etc.), are written in Ruby, and Rubinius regards them as third-party Ruby application code. This approach makes it much easier to understand and analyze the entire system of Rubinius tools.

Future plans

Our plans are a very sore subject, because forecasting the future remains an inaccurate science. But based on the goal of concentrating efforts around parallel and distributed calculations, the following priority areas of work can be identified:

1. In Rubinius there is no global interpreter lock, but we still have much to improve the management of parallel threads in the system. During certain phases of garbage collection, certain JIT operations, for fork / exec, we still have to stop all threads. There is still need to work and simplify the existing problems.
2. Instead of GIL in Rubinius, local locks occur in various places. They should also be reduced, more efficient on multi-core processors, for example, through the use of modern non-blocking parallel data structures.
3. The garbage collector copes fairly quickly and rarely stops the process, however, we still have to work on it.
4. The JIT compiler already speeds up Ruby code by 2-4 times compared to the execution of a bayktod, but we know that we can do better, we will try to improve the understanding of the semantics of the language in order to avoid unnecessary memory allocations and object accounting, which negatively affects performance. The JIT toolkit itself will be modified to increase the speed of developing and testing new ideas for optimizing Ruby.

Gems as Components

The ability to create a system from components means managing a content complex structure. But in Ruby, we are used to packaging and distributing components as gem packages.

Rubinius wants to bring the benefits of using continuous integration into Ruby development, and in this we want to make extensive use of the infrastructure of gem packages. Their use greatly simplified Rubinius itself - all its main components became independent gem packages. They became easy and fast to update one by one. In addition, the entire standard Rubinius library has also been converted into gem packages. It was hard work, because the standard library was the oldest Ruby code.

So, distribution and parallelism are not the future, but the present. They are extremely important for the success of your service. Because of this, many young and talented developers left Ruby and went to Erlang, Go, Clojure or Node. But Ruby is a great language, and Rubinius is designed to provide developers with high-end tools and technologies that allow Ruby to be a strong competitor to other languages. If you like writing in Ruby, then you no longer need to look for a more productive alternative because of some technical limitations. Let's build the future together!