Could JavaScript Power A Significant Future Ruby Implementation or VM?
This week you may have heard about "Chrome," a new Web browser being developed by Google (if you haven't, read this online comic book that demonstrates its worthiness). Associated with Chrome is V8, a new open source JavaScript engine that's designed to execute JavaScript code at never-seen-before speeds.
All this reminded Marc-André Cournoyer (of Thin fame) of HotRuby (see previously on Ruby Inside), an experimental JavaScript-based virtual machine that can run YARV-compiled Ruby code, and he set out to test the performance of Ruby code running on HotRuby on top of V8. The results are far from scientific and many commenters have pointed out flaws, but Marc's observations are a great first step toward seriously considering the possibility of using JavaScript as an execution route for Ruby. It also appears that Hongli Lai and Ninh Bui of Phusion (of mod_rails / Passenger fame) are considering the possibilities.
JavaScript is a reasonably unique language in that it can support most (all?) of the patterns and styles of programming that Rubyists are familiar with, even if the code doesn't read as well. This could make JavaScript a perfect target language not only for a virtual machine (as with HotRuby) but as a language to convert Ruby into for further use / execution. We're going to feature these projects separately on Ruby Inside in the future, but projects like Red and RubyJS could eventually make this a reality, and turn JavaScript itself into another form of Ruby implementation by proxy. Exciting times!
September 6, 2008 at 2:38 am
Also Johnson:
http://tenderlovemaking.com/2008/04/23/take-it-to-the-limit-one-more-time/
http://github.com/jbarnette/johnson/tree/master
September 6, 2008 at 9:44 am
The same has been said of the Smalltalk virtual machines for years with Ruby. As Gemstone and JRuby guys have found, the devil is truly in the details of supporting *all* of MRI's features -- even the stupid ones. Javascript has fewer of these problems because it was based on the ECMAScript standard designed by committee and the committee weeded out a lot of the stupidity that makes Ruby difficult to implement. While I enthusiastically agree with 95% of Matz' 1.8.x design decisions of the Ruby language, MRI's implementation is embarrassing.
The Strongtalk virtual machine has been lying around for years just waiting for technologies like Ruby to pick it up and learn from it. There're a few really fascinating whitepapers on their website about how the Strongtalk and Self VM teams implemented polymorphic inline call site caching and algorithms for generating types inferences at runtime. (At least one of the principal developers from those VM projects works on TraceMonkey now)
At some point, ideally for Ruby 2.0, the Ruby community needs a committee to clean up the poor design decisions that exist in 1.8/1.9 that make writing an implementation so difficult and harm the language's elegance. It's far too much work for one person and far too important to be trusted to one person. When this is done, the feasibility of fully using these Javascript and Smalltalk technologies will be more feasible.
September 7, 2008 at 5:56 pm
"Chrome is V8, a new open source JavaScript engine that's designed to execute JavaScript code at never-seen-before speeds."
The new Javascript VM in Firefox 3.1beta1 (tracemonkey) is faster or similar in speed to Chrome V8 in many tests.
(you must enable it first in about:config)