RubyConf 2010: the present and the future of Ruby (II)

I suggest you read the translation of the third part of Ruby’s author’s report, Yukihiro Matsumoto, on RubyConf 2010, published in his blog in Japanese, in which he talks about Rite, the minimalist and modular implementation of Ruby for embedded systems - smart home, TV or robots.

The translation is supplemented with the presentation material.

On the very first day, Dave Thomas in his report mentioned three important things and, of course, there was diversity among them. Diversity is important.

If we talk about Ruby, then to this day there are many different implementations.

• CRuby (1.9, 1.8)
• Juby
• Rubinius
• IronRuby
• Macruby
• MagLev

In addition to the listed complete implementations of the language, there are also partial implementations, “Ruby-like” languages, and it is difficult for me to even guess how many of them there really can be.
')

Programmers who prefer Python used to say: “Look at CPython, and Jython, and IronPython. Is there something similar for Ruby (and Perl)? These languages ​​are too complex for the emergence of alternative implementations. " Now there are even more implementations of Ruby. (However, it’s good that new Python interpreters are developing, like PyPy.)

On the other hand, diversity requires sacrifice. Support for many different platforms requires the investment of a large number of forces, especially if these are new implementations that have not yet reached such a level of compatibility as JRuby, CRuby, MacRuby and Rubinius.

I know the price to pay for diversity, and it's worth it.

In fact, I praise diversity so much because I want to increase it further by writing a new interpreter.

It is called RiteVM, and is intended for embedded devices.


Ruby was originally developed for Unix, but in embedded systems, Unix and POSIX interfaces are often absent as unnecessary.

Since the performance of embedded systems has recently increased significantly, it is often the case that real-time execution can be neglected in favor of using a higher level language.

So, we are developing a new interpreter.

• The interpreter will support a minimal subset of the Ruby language. Most of the I / O and file functions will be removed (but may be added later).
• The implementation will be similar to Lua (but with a better language).
• The interpreter will be modular. For example, you can implement a translator without eval. Many parameters can be set at compilation: Float can be implemented as a float or double, Fixnum - as an int, long, long long or something else. String functions will work with ASCII or UTF-8. The interpreter will be much less abstracted from the platform, for example, in the implementation for simple devices there may be no file I / O.
• Floating-point numbers will be implemented as immediate values, which will significantly speed up calculations. (Note: in Ruby MRI, integers are implemented in such a way that they occupy one platform pointer in memory; Float is an object and takes up substantially more memory.)
• Minimum requirements include the C99 compiler. Rite will run on a PC, within RTOS or by itself, and use less memory and processor resources.
• A registered virtual machine with a 32-bit word and a set of instructions similar to Lua will be used.
• To reduce mark & ​​sweep delays, the garbage collector will be smooth [incremental - hereinafter approx. perev.], and, probably, in view of generations [generational].

In addition, Professor Tanaka from Kyushi Institute of Technology is developing a “Ruby-chip”: an FPGA- based MIPS-like processor, to which several instructions have been added that make it easier to find the method and garbage collection.


Rite is the code name of the project at the time of its development, which is carried out as part of the 2010 Regional Project for Research and Development [Regional Innovation Research and Development Project], conducted by the Ministry of Economics [of Japan].

The result will be a Ruby subset implementation that can be applied as:

• Script engine for games
• Software for the system "Smart Home",
• Interpreter in the digital TV firmware,
• To control robots in other embedded systems where real-time response is not required.

Of course, I do not think that all this will appear right now, but in a few years if our business succeeds, this is quite possible.

Yes, I almost forgot.

Frequently asked Questions

When will Rite be ready?
I dont know. As I mentioned, this is a two-year (2010-2011) project funded by the Japanese government.

Will the RiteVM source codes be open?
Yes. Most likely, under the MIT license. However, under a contract with the government, we need a business model. We will probably choose GPL plus a subscription (as MySQL is distributed).

Will RiteVM replace CRuby?
Not at all. Rite has only a small part of the capabilities of a full implementation, such as CRuby.

What will the C API look like?
API RiteVM will be significantly different from CRuby. The CRuby interface is very easy to use, but it is more difficult to implement [in embedded environments]. Theoretically, compatibility layer development is possible, but we do not plan to do this.

Will RiteVM support multiple languages ​​[Multilingualization]?
No, you can only choose ACSII or UTF-8 when compiling. There will not be standard libraries for converting encodings either.

Will native threads be supported?
No, RiteVM itself will not support streams. If you want to use OS threads, you can run each on an interpreter. [Fibers] can be implemented in the virtual machine, but so far we have not planned this.

Will RiteVM be faster than YARV / JRuby / Rubinius?
Hardly. Improvements will mainly affect floating point operations, like how they will be implemented through immediate values ​​[immediates].

How can I contribute to the development of RiteVM?
Please wait until the source code is open. We will post it on github.

Rite? Sounds familiar.
In 2003, Rite was proposed as a codename for the implementation of Ruby 2.0 in my RubyConf report. In the end, the YARV virtual machine was used, and I just use the old name. It is derived from “Ruby” and “lite”.

CRuby is Matz. Are you going to stop working on CRuby?
On the one hand, I no longer make a significant contribution to the development of CRuby, but I am not going to stop it. CRuby will remain the main Ruby implementation, and I will continue to work as a language architect and community leader.

Translation of the second part of the report is also published in Habré.