
Rubinius Retort : What "Ruby in Ruby" really means - raganwald
http://blog.fallingsnow.net/2008/04/28/rubinius-retort/
======
demallien
I have to say that I'm not too thrilled by this move to VMs by everyone in the
Ruby world. One of the things that I absolutely love about Ruby 1.8 is that
when performance is a dog I can just replace the slow Ruby code with fast C
code. Writing extensions is dead easy. With a VM this can ony be a much more
convoluted process.

An example (which is a bit Russian Dolls nested in nature) - I recently wrote
a tool that takes various modules from a C project with an embedded target,
and places them inside a VM to obfuscate the code. Because it's embedded code,
we needed to be able to only place selected modules in the VM, for performance
reasons, but we needed the transition between VM and native C code to be
transparent (Basically, everything is coded in C, but we compile some modules
for the VM, not the target).

To make this work, I wrote a tool that generates glue code to cross the
interface. Code is generated automatically for both sides of the interface.
This requires the use of a C parser, which for performance reasons is mostly
written in C. But the high level analysis is done in Ruby, as is code
generation, various sandbox management tasks and other peripheral tasks. If I
couldn't have written the front end of the parser in C using yacc, the
performance would be horrible. As the sandbox is quite large (300 000 lines of
code), performance of the parser is a major issue. I don't know how easy it is
going to be to port this stuff to the new impls....

