I'm sure many of you recall last year's presentation[1] "Ruby: Past, Present, Future". It took place almost a full year ago, on June 16th. At the time, we noted how several of our main subjects under discussion could evolve in different ways. Let us review and reflect on those subjects once more.
First off, let's get one major subject out of the way: the Ruby language itself. That hasn't changed much, and not likely that it will. The design is solid, or at least solidified. Much as it was a year ago, changes planned for Ruby 2.0 are small, incremental; and even of those, the majority count as wart-fixers (e.g. less surprising handling of closure scopes). So everything we said about Ruby as a language a year ago, is still as true today.
Now for the other major subject of that presentation: implementation. There, we have many changes and developments.
_YARV_ is still looming in the all-too-distant horizon, as predicted a year ago. There's a lot of interest in it, following the growing concerns over MRI (Mat'z Ruby Implementation,the current 1.8.x implementation everyone's using) performance. Just a few days ago there was another wave of speculation about Twitter abandoning Rails due to poor performance, and they're not the only ones.
YARV still, however, suffers from the same problems we discussed yesteryear, namely: lack of significant improvement over MRI. True, it is bytecode-compiled, and yes, it is faster and better than MRI. But not by much. Last year, this estimate was mostly a speculation, based on analysis of the architecture, but since that time YARV has reached an increasingly stable state, and benchmarks are becoming more meaningful. Results, as expected, are not exciting. YARV is generally no more than 50% faster than MRI[2].
Ruby needs to run at least several times faster to compete with even just some of the faster dynamic languages in its class (Python, PHP, Perl). YARV currently doesn't provide that, or anything really close to that, while several of those rivals are constantly improving their own VM performance, both evolutionary (with small incremental upgrades) and revolutionary (with ideas like JIT compilation, partial type declaration / inference etc.)
_JRuby_, as predicted, has continued its determined, stable progress towards a solid, fast (but not incredibly fast) Ruby implementation. At the time, we discussed at length how JRuby is evolutionary, rather than revolutionary; how it aims at modest goals ("faster than MRI", not "as fast as compiled C").
Very little of what JRuby does is experimental or ground-breaking. While this may sound unexciting, it also means there's not much soul-searching or basic research involved in the core parts of the project. JRuby has been progressing by slow, measured, but solid steps; and indeed, of all the projects we've discussed, it's currently in the best shape.
JRuby is currently a 1.8.x-compatible Ruby implementation. It runs Rails well. While it is not generally considered quite as fast as YARV[3] in interpreted mode, it's running 1.8.x code, and not the unstable 1.9 version of the language. This makes JRuby the fastest viable 1.8.x platform, i.e. the best performing Ruby platform out there that's actually viable for production right now.
Consequently, there's growing interest in JRuby as a production Ruby platform[4]. This is aided by its natural integration with the JVM, the Java libraries, applications and tool-chains. However, a major obstacle also stems from JRuby's slow, cautious progress - it's not the revolutionary Ruby implementations that users yearn for. Being generally a bit faster than MRI is certainly a great achievement for an implementation project, but doesn't make it an obvious choice over MRI; if you really care about performance, both are pretty slow.
_Rubinius_ has been through a lot this year, fulfilling at least one prediction we made about it: of the major re-implementation efforts, it's certainly walking the most interesting, twisted path.
A thorough survey of the twists and turns Rubinius went through is much beyond the scope of this post; for anyone truly interested in Rubinius, the recent presentation by Rubinius's lead developer, Evan Phoenix, at the Mountain West conference[5] could serve as a good introduction. We'll only focus on a few short points.
Rubinius's original slogan has been "Ruby implemented in Ruby". Theoretically and practically, it is possible to build in a dynamic language a fast virtual machine to host itself. Smalltalk has already done that with the Smalltalk-80 design that dates back to the 80s[6]. Some of these implementations are very fast[7] compared to Ruby, while offering closely comparable levels of dynamism and flexibility. In fact, one way for Ruby's performance problems to end is by following Smalltalk's implementation strategies; the languages are similar enough from a performance-analysis point of view, to make that very feasible.
The project has gone through many changes and shifts during the last year. Just little more than a month ago, it was decided to completely rewrite one of its key parts - the Shotgun virtual machine (and in C++ instead of C). While there are many good reasons[8] for the rewrite, it will still delay progress.
Rubinius is arguably still the most interesting Ruby implementation project around. JRuby deserves a lot of respect for becoming, slowly but steadily, the best currently-viable Ruby implementation. Rubinius definitely has a long way just to get to where JRuby is right now. But it has been getting a lot of attention and love[9], with several top notch Ruby hackers working on it full time.
_Other development_:
The above covers the major implementations we discussed last year. Not much more is known or can be said about IronRuby; the same concerns we discussed last year were about as valid then as they are now.
Three new up-and-coming implementations that I would like to mention are HotRuby[10], IronMonkey[11] and MagLev[12].
_HotRuby_ and _IronMonkey_ are essentially efforts to run Ruby on ECMAScript platforms (ECMAScript is the abstract standard on which both Javascript and Actionscript [the Flash programming language] are based).
HotRuby is essentially a hack: you embed Ruby code in your DOM, which HotRuby then extracts and sends to the server for processing by Ruby 1.9 CGI. The results of the Ruby execution (all done on the server) are received at the client as JSON and acted upon by HotRuby. There was a lot of buzz about this about a month ago, and I'm not sure why. Notably John Resig (jQuery's lead developer) blogged about it[13], and it then got Slashdotted. One of the main points in the blog is that the whole setup is faster than the same code running locally Ruby 1.8.2, which shouldn't surprise anyone familiar with Ruby platforms who knows that 1.9 is significantly faster than 1.8.2 for comparable code. So maybe this whole thing was a misunderstanding. In any case, it's a nifty AJAX trick.
IronMonkey is much more interesting, but not a whole lot is currently known about it. It's basically an attempt to map Python and Ruby to Tamarin at the bytecode level. On principle this could be a huge thing, because Tamarin (an OSS ECMAScript VM utilzing state-of-the-art JIT technologies) is extremely fast. Via the ActionMonkey[14] project, it's being integrated into SpiderMonkey (the Javascript engine of Mozilla/Firefox), so it would be on every desktop running Firefox 4, perhaps as soon as late this year.
Unfortunately, though ActionMonkey is making good progress, it doesn't seem like IronMonkey is a major priority for Mozilla, compared to its main goal of running Javascript (fast). In truth, the whole thing reminds one of Pirate[15] and Cardinal[16]: an attempt to support additional languages (Ruby and Python) on a new runtime platform (Parrot / Tamarin) that is capalbe, technologically, of running those languages, but is clearly focused on a different target implementation (Perl6 / Javascript 2.0). Still, Ruby running natively on Tamarin could be huge, and not just because of Ruby's current heavy usage for web development.
Very interesting! Thank you Adam. Antonio Cangiano ([3] "The Great Ruby Shootout") also posts a weekly "This Week in Ruby" which is very informative. He reports on these developments as they unfold and it can be very interesting. Here's a link to his latest post:
On Sun, May 11, 2008 at 9:07 AM, Adam Fine <a...@adamfine.net> wrote: > I'm sure many of you recall last year's presentation[1] "Ruby: Past, > Present, Future". It took place almost a full year ago, on June 16th. At the > time, we noted how several of our main subjects under discussion could > evolve in different ways. Let us review and reflect on those subjects once > more.
> First off, let's get one major subject out of the way: the Ruby language > itself. That hasn't changed much, and not likely that it will. The design is > solid, or at least solidified. Much as it was a year ago, changes planned > for Ruby 2.0 are small, incremental; and even of those, the majority count > as wart-fixers (e.g. less surprising handling of closure scopes). So > everything we said about Ruby as a language a year ago, is still as true > today.
> Now for the other major subject of that presentation: implementation. > There, we have many changes and developments.
> _YARV_ is still looming in the all-too-distant horizon, as predicted a year > ago. There's a lot of interest in it, following the growing concerns over > MRI (Mat'z Ruby Implementation,the current 1.8.x implementation everyone's > using) performance. Just a few days ago there was another wave of > speculation about Twitter abandoning Rails due to poor performance, and > they're not the only ones.
> YARV still, however, suffers from the same problems we discussed > yesteryear, namely: lack of significant improvement over MRI. True, it is > bytecode-compiled, and yes, it is faster and better than MRI. But not by > much. Last year, this estimate was mostly a speculation, based on analysis > of the architecture, but since that time YARV has reached an increasingly > stable state, and benchmarks are becoming more meaningful. Results, as > expected, are not exciting. YARV is generally no more than 50% faster than > MRI[2].
> Ruby needs to run at least several times faster to compete with even just > some of the faster dynamic languages in its class (Python, PHP, Perl). YARV > currently doesn't provide that, or anything really close to that, while > several of those rivals are constantly improving their own VM performance, > both evolutionary (with small incremental upgrades) and revolutionary (with > ideas like JIT compilation, partial type declaration / inference etc.)
> _JRuby_, as predicted, has continued its determined, stable progress > towards a solid, fast (but not incredibly fast) Ruby implementation. At the > time, we discussed at length how JRuby is evolutionary, rather than > revolutionary; how it aims at modest goals ("faster than MRI", not "as fast > as compiled C").
> Very little of what JRuby does is experimental or ground-breaking. While > this may sound unexciting, it also means there's not much soul-searching or > basic research involved in the core parts of the project. JRuby has been > progressing by slow, measured, but solid steps; and indeed, of all the > projects we've discussed, it's currently in the best shape.
> JRuby is currently a 1.8.x-compatible Ruby implementation. It runs Rails > well. While it is not generally considered quite as fast as YARV[3] in > interpreted mode, it's running 1.8.x code, and not the unstable 1.9 version > of the language. This makes JRuby the fastest viable 1.8.x platform, i.e. > the best performing Ruby platform out there that's actually viable for > production right now.
> Consequently, there's growing interest in JRuby as a production Ruby > platform[4]. This is aided by its natural integration with the JVM, the Java > libraries, applications and tool-chains. However, a major obstacle also > stems from JRuby's slow, cautious progress - it's not the revolutionary Ruby > implementations that users yearn for. Being generally a bit faster than MRI > is certainly a great achievement for an implementation project, but doesn't > make it an obvious choice over MRI; if you really care about performance, > both are pretty slow.
> _Rubinius_ has been through a lot this year, fulfilling at least one > prediction we made about it: of the major re-implementation efforts, it's > certainly walking the most interesting, twisted path.
> A thorough survey of the twists and turns Rubinius went through is much > beyond the scope of this post; for anyone truly interested in Rubinius, the > recent presentation by Rubinius's lead developer, Evan Phoenix, at the > Mountain West conference[5] could serve as a good introduction. We'll only > focus on a few short points.
> Rubinius's original slogan has been "Ruby implemented in Ruby". > Theoretically and practically, it is possible to build in a dynamic language > a fast virtual machine to host itself. Smalltalk has already done that with > the Smalltalk-80 design that dates back to the 80s[6]. Some of these > implementations are very fast[7] compared to Ruby, while offering closely > comparable levels of dynamism and flexibility. In fact, one way for Ruby's > performance problems to end is by following Smalltalk's implementation > strategies; the languages are similar enough from a performance-analysis > point of view, to make that very feasible.
> The project has gone through many changes and shifts during the last year. > Just little more than a month ago, it was decided to completely rewrite one > of its key parts - the Shotgun virtual machine (and in C++ instead of C). > While there are many good reasons[8] for the rewrite, it will still delay > progress.
> Rubinius is arguably still the most interesting Ruby implementation project > around. JRuby deserves a lot of respect for becoming, slowly but steadily, > the best currently-viable Ruby implementation. Rubinius definitely has a > long way just to get to where JRuby is right now. But it has been getting a > lot of attention and love[9], with several top notch Ruby hackers working on > it full time.
> _Other development_:
> The above covers the major implementations we discussed last year. Not much > more is known or can be said about IronRuby; the same concerns we discussed > last year were about as valid then as they are now.
> Three new up-and-coming implementations that I would like to mention are > HotRuby[10], IronMonkey[11] and MagLev[12].
> _HotRuby_ and _IronMonkey_ are essentially efforts to run Ruby on > ECMAScript platforms (ECMAScript is the abstract standard on which both > Javascript and Actionscript [the Flash programming language] are based).
> HotRuby is essentially a hack: you embed Ruby code in your DOM, which > HotRuby then extracts and sends to the server for processing by Ruby 1.9 > CGI. The results of the Ruby execution (all done on the server) are received > at the client as JSON and acted upon by HotRuby. There was a lot of buzz > about this about a month ago, and I'm not sure why. Notably John Resig > (jQuery's lead developer) blogged about it[13], and it then got Slashdotted. > One of the main points in the blog is that the whole setup is faster than > the same code running locally Ruby 1.8.2, which shouldn't surprise anyone > familiar with Ruby platforms who knows that 1.9 is significantly faster than > 1.8.2 for comparable code. So maybe this whole thing was a misunderstanding. > In any case, it's a nifty AJAX trick.
> IronMonkey is much more interesting, but not a whole lot is currently known > about it. It's basically an attempt to map Python and Ruby to Tamarin at the > bytecode level. On principle this could be a huge thing, because Tamarin (an > OSS ECMAScript VM utilzing state-of-the-art JIT technologies) is extremely > fast. Via the ActionMonkey[14] project, it's being integrated into > SpiderMonkey (the Javascript engine of Mozilla/Firefox), so it would be on > every desktop running Firefox 4, perhaps as soon as late this year.
> Unfortunately, though ActionMonkey is making good progress, it doesn't seem > like IronMonkey is a major priority for Mozilla, compared to its main goal > of running Javascript (fast). In truth, the whole thing reminds one of > Pirate[15] and Cardinal[16]: an attempt to support additional languages > (Ruby and Python) on a new runtime platform (Parrot / Tamarin) that is > capalbe, technologically, of running those languages, but is clearly focused > on a different target implementation (Perl6 / Javascript 2.0). Still, Ruby > running natively on Tamarin could be huge, and not just because of Ruby's > current heavy usage for web development.
> Hope you enjoyed reading all that, and take care,
> I'm sure many of you recall last year's presentation[1] "Ruby: Past,
> Present, Future". It took place almost a full year ago, on June 16th. At the
> time, we noted how several of our main subjects under discussion could
> evolve in different ways. Let us review and reflect on those subjects once
> more.
> First off, let's get one major subject out of the way: the Ruby language
> itself. That hasn't changed much, and not likely that it will. The design is
> solid, or at least solidified. Much as it was a year ago, changes planned
> for Ruby 2.0 are small, incremental; and even of those, the majority count
> as wart-fixers (e.g. less surprising handling of closure scopes). So
> everything we said about Ruby as a language a year ago, is still as true
> today.
> Now for the other major subject of that presentation: implementation. There,
> we have many changes and developments.
> _YARV_ is still looming in the all-too-distant horizon, as predicted a year
> ago. There's a lot of interest in it, following the growing concerns over
> MRI (Mat'z Ruby Implementation,the current 1.8.x implementation everyone's
> using) performance. Just a few days ago there was another wave of
> speculation about Twitter abandoning Rails due to poor performance, and
> they're not the only ones.
> YARV still, however, suffers from the same problems we discussed yesteryear,
> namely: lack of significant improvement over MRI. True, it is
> bytecode-compiled, and yes, it is faster and better than MRI. But not by
> much. Last year, this estimate was mostly a speculation, based on analysis
> of the architecture, but since that time YARV has reached an increasingly
> stable state, and benchmarks are becoming more meaningful. Results, as
> expected, are not exciting. YARV is generally no more than 50% faster than
> MRI[2].
> Ruby needs to run at least several times faster to compete with even just
> some of the faster dynamic languages in its class (Python, PHP, Perl). YARV
> currently doesn't provide that, or anything really close to that, while
> several of those rivals are constantly improving their own VM performance,
> both evolutionary (with small incremental upgrades) and revolutionary (with
> ideas like JIT compilation, partial type declaration / inference etc.)
> _JRuby_, as predicted, has continued its determined, stable progress towards
> a solid, fast (but not incredibly fast) Ruby implementation. At the time, we
> discussed at length how JRuby is evolutionary, rather than revolutionary;
> how it aims at modest goals ("faster than MRI", not "as fast as compiled
> C").
> Very little of what JRuby does is experimental or ground-breaking. While
> this may sound unexciting, it also means there's not much soul-searching or
> basic research involved in the core parts of the project. JRuby has been
> progressing by slow, measured, but solid steps; and indeed, of all the
> projects we've discussed, it's currently in the best shape.
> JRuby is currently a 1.8.x-compatible Ruby implementation. It runs Rails
> well. While it is not generally considered quite as fast as YARV[3] in
> interpreted mode, it's running 1.8.x code, and not the unstable 1.9 version
> of the language. This makes JRuby the fastest viable 1.8.x platform, i.e.
> the best performing Ruby platform out there that's actually viable for
> production right now.
> Consequently, there's growing interest in JRuby as a production Ruby
> platform[4]. This is aided by its natural integration with the JVM, the Java
> libraries, applications and tool-chains. However, a major obstacle also
> stems from JRuby's slow, cautious progress - it's not the revolutionary Ruby
> implementations that users yearn for. Being generally a bit faster than MRI
> is certainly a great achievement for an implementation project, but doesn't
> make it an obvious choice over MRI; if you really care about performance,
> both are pretty slow.
> _Rubinius_ has been through a lot this year, fulfilling at least one
> prediction we made about it: of the major re-implementation efforts, it's
> certainly walking the most interesting, twisted path.
> A thorough survey of the twists and turns Rubinius went through is much
> beyond the scope of this post; for anyone truly interested in Rubinius, the
> recent presentation by Rubinius's lead developer, Evan Phoenix, at the
> Mountain West conference[5] could serve as a good introduction. We'll only
> focus on a few short points.
> Rubinius's original slogan has been "Ruby implemented in Ruby".
> Theoretically and practically, it is possible to build in a dynamic language
> a fast virtual machine to host itself. Smalltalk has already done that with
> the Smalltalk-80 design that dates back to the 80s[6]. Some of these
> implementations are very fast[7] compared to Ruby, while offering closely
> comparable levels of dynamism and flexibility. In fact, one way for Ruby's
> performance problems to end is by following Smalltalk's implementation
> strategies; the languages are similar enough from a performance-analysis
> point of view, to make that very feasible.
> The project has gone through many changes and shifts during the last year.
> Just little more than a month ago, it was decided to completely rewrite one
> of its key parts - the Shotgun virtual machine (and in C++ instead of C).
> While there are many good reasons[8] for the rewrite, it will still delay
> progress.
> Rubinius is arguably still the most interesting Ruby implementation project
> around. JRuby deserves a lot of respect for becoming, slowly but steadily,
> the best currently-viable Ruby implementation. Rubinius definitely has a
> long way just to get to where JRuby is right now. But it has been getting a
> lot of attention and love[9], with several top notch Ruby hackers working on
> it full time.
> _Other development_:
> The above covers the major implementations we discussed last year. Not much
> more is known or can be said about IronRuby; the same concerns we discussed
> last year were about as valid then as they are now.
> Three new up-and-coming implementations that I would like to mention are
> HotRuby[10], IronMonkey[11] and MagLev[12].
> _HotRuby_ and _IronMonkey_ are essentially efforts to run Ruby on ECMAScript
> platforms (ECMAScript is the abstract standard on which both Javascript and
> Actionscript [the Flash programming language] are based).
> HotRuby is essentially a hack: you embed Ruby code in your DOM, which
> HotRuby then extracts and sends to the server for processing by Ruby 1.9
> CGI. The results of the Ruby execution (all done on the server) are received
> at the client as JSON and acted upon by HotRuby. There was a lot of buzz
> about this about a month ago, and I'm not sure why. Notably John Resig
> (jQuery's lead developer) blogged about it[13], and it then got Slashdotted.
> One of the main points in the blog is that the whole setup is faster than
> the same code running locally Ruby 1.8.2, which shouldn't surprise anyone
> familiar with Ruby platforms who knows that 1.9 is significantly faster than
> 1.8.2 for comparable code. So maybe this whole thing was a misunderstanding.
> In any case, it's a nifty AJAX trick.
> IronMonkey is much more interesting, but not a whole lot is currently known
> about it. It's basically an attempt to map Python and Ruby to Tamarin at the
> bytecode level. On principle this could be a huge thing, because Tamarin (an
> OSS ECMAScript VM utilzing state-of-the-art JIT technologies) is extremely
> fast. Via the ActionMonkey[14] project, it's being integrated into
> SpiderMonkey (the Javascript engine of Mozilla/Firefox), so it would be on
> every desktop running Firefox 4, perhaps as soon as late this year.
> Unfortunately, though ActionMonkey is making good progress, it doesn't seem
> like IronMonkey is a major priority for Mozilla, compared to its main goal
> of running Javascript (fast). In truth, the whole thing reminds one of
> Pirate[15] and Cardinal[16]: an attempt to support additional languages
> (Ruby and Python) on a new runtime platform (Parrot / Tamarin) that is
> capalbe, technologically, of running those languages, but is clearly focused
> on a different target implementation (Perl6 / Javascript 2.0). Still, Ruby
> running natively on Tamarin could be huge, and not just because of Ruby's
> current heavy usage for web development.
> Hope you enjoyed reading all that, and take care,
On Sun, May 11, 2008 at 12:41 PM, Ehud <ehud...@gmail.com> wrote:
> Thanks Adam, a great read...
> On May 11, 9:07 am, "Adam Fine" <a...@adamfine.net> wrote: > > I'm sure many of you recall last year's presentation[1] "Ruby: Past, > > Present, Future". It took place almost a full year ago, on June 16th. At > the > > time, we noted how several of our main subjects under discussion could > > evolve in different ways. Let us review and reflect on those subjects > once > > more.
> > First off, let's get one major subject out of the way: the Ruby language > > itself. That hasn't changed much, and not likely that it will. The > design is > > solid, or at least solidified. Much as it was a year ago, changes > planned > > for Ruby 2.0 are small, incremental; and even of those, the majority > count > > as wart-fixers (e.g. less surprising handling of closure scopes). So > > everything we said about Ruby as a language a year ago, is still as true > > today.
> > Now for the other major subject of that presentation: implementation. > There, > > we have many changes and developments.
> > _YARV_ is still looming in the all-too-distant horizon, as predicted a > year > > ago. There's a lot of interest in it, following the growing concerns > over > > MRI (Mat'z Ruby Implementation,the current 1.8.x implementation > everyone's > > using) performance. Just a few days ago there was another wave of > > speculation about Twitter abandoning Rails due to poor performance, and > > they're not the only ones.
> > YARV still, however, suffers from the same problems we discussed > yesteryear, > > namely: lack of significant improvement over MRI. True, it is > > bytecode-compiled, and yes, it is faster and better than MRI. But not by > > much. Last year, this estimate was mostly a speculation, based on > analysis > > of the architecture, but since that time YARV has reached an > increasingly > > stable state, and benchmarks are becoming more meaningful. Results, as > > expected, are not exciting. YARV is generally no more than 50% faster > than > > MRI[2].
> > Ruby needs to run at least several times faster to compete with even > just > > some of the faster dynamic languages in its class (Python, PHP, Perl). > YARV > > currently doesn't provide that, or anything really close to that, while > > several of those rivals are constantly improving their own VM > performance, > > both evolutionary (with small incremental upgrades) and revolutionary > (with > > ideas like JIT compilation, partial type declaration / inference etc.)
> > _JRuby_, as predicted, has continued its determined, stable progress > towards > > a solid, fast (but not incredibly fast) Ruby implementation. At the > time, we > > discussed at length how JRuby is evolutionary, rather than > revolutionary; > > how it aims at modest goals ("faster than MRI", not "as fast as compiled > > C").
> > Very little of what JRuby does is experimental or ground-breaking. While > > this may sound unexciting, it also means there's not much soul-searching > or > > basic research involved in the core parts of the project. JRuby has been > > progressing by slow, measured, but solid steps; and indeed, of all the > > projects we've discussed, it's currently in the best shape.
> > JRuby is currently a 1.8.x-compatible Ruby implementation. It runs Rails > > well. While it is not generally considered quite as fast as YARV[3] in > > interpreted mode, it's running 1.8.x code, and not the unstable 1.9 > version > > of the language. This makes JRuby the fastest viable 1.8.x platform, > i.e. > > the best performing Ruby platform out there that's actually viable for > > production right now.
> > Consequently, there's growing interest in JRuby as a production Ruby > > platform[4]. This is aided by its natural integration with the JVM, the > Java > > libraries, applications and tool-chains. However, a major obstacle also > > stems from JRuby's slow, cautious progress - it's not the revolutionary > Ruby > > implementations that users yearn for. Being generally a bit faster than > MRI > > is certainly a great achievement for an implementation project, but > doesn't > > make it an obvious choice over MRI; if you really care about > performance, > > both are pretty slow.
> > _Rubinius_ has been through a lot this year, fulfilling at least one > > prediction we made about it: of the major re-implementation efforts, > it's > > certainly walking the most interesting, twisted path.
> > A thorough survey of the twists and turns Rubinius went through is much > > beyond the scope of this post; for anyone truly interested in Rubinius, > the > > recent presentation by Rubinius's lead developer, Evan Phoenix, at the > > Mountain West conference[5] could serve as a good introduction. We'll > only > > focus on a few short points.
> > Rubinius's original slogan has been "Ruby implemented in Ruby". > > Theoretically and practically, it is possible to build in a dynamic > language > > a fast virtual machine to host itself. Smalltalk has already done that > with > > the Smalltalk-80 design that dates back to the 80s[6]. Some of these > > implementations are very fast[7] compared to Ruby, while offering > closely > > comparable levels of dynamism and flexibility. In fact, one way for > Ruby's > > performance problems to end is by following Smalltalk's implementation > > strategies; the languages are similar enough from a performance-analysis > > point of view, to make that very feasible.
> > The project has gone through many changes and shifts during the last > year. > > Just little more than a month ago, it was decided to completely rewrite > one > > of its key parts - the Shotgun virtual machine (and in C++ instead of > C). > > While there are many good reasons[8] for the rewrite, it will still > delay > > progress.
> > Rubinius is arguably still the most interesting Ruby implementation > project > > around. JRuby deserves a lot of respect for becoming, slowly but > steadily, > > the best currently-viable Ruby implementation. Rubinius definitely has a > > long way just to get to where JRuby is right now. But it has been > getting a > > lot of attention and love[9], with several top notch Ruby hackers > working on > > it full time.
> > _Other development_:
> > The above covers the major implementations we discussed last year. Not > much > > more is known or can be said about IronRuby; the same concerns we > discussed > > last year were about as valid then as they are now.
> > Three new up-and-coming implementations that I would like to mention are > > HotRuby[10], IronMonkey[11] and MagLev[12].
> > _HotRuby_ and _IronMonkey_ are essentially efforts to run Ruby on > ECMAScript > > platforms (ECMAScript is the abstract standard on which both Javascript > and > > Actionscript [the Flash programming language] are based).
> > HotRuby is essentially a hack: you embed Ruby code in your DOM, which > > HotRuby then extracts and sends to the server for processing by Ruby 1.9 > > CGI. The results of the Ruby execution (all done on the server) are > received > > at the client as JSON and acted upon by HotRuby. There was a lot of buzz > > about this about a month ago, and I'm not sure why. Notably John Resig > > (jQuery's lead developer) blogged about it[13], and it then got > Slashdotted. > > One of the main points in the blog is that the whole setup is faster > than > > the same code running locally Ruby 1.8.2, which shouldn't surprise > anyone > > familiar with Ruby platforms who knows that 1.9 is significantly faster > than > > 1.8.2 for comparable code. So maybe this whole thing was a > misunderstanding. > > In any case, it's a nifty AJAX trick.
> > IronMonkey is much more interesting, but not a whole lot is currently > known > > about it. It's basically an attempt to map Python and Ruby to Tamarin at > the > > bytecode level. On principle this could be a huge thing, because Tamarin > (an > > OSS ECMAScript VM utilzing state-of-the-art JIT technologies) is > extremely > > fast. Via the ActionMonkey[14] project, it's being integrated into > > SpiderMonkey (the Javascript engine of Mozilla/Firefox), so it would be > on > > every desktop running Firefox 4, perhaps as soon as late this year.
> > Unfortunately, though ActionMonkey is making good progress, it doesn't > seem > > like IronMonkey is a major priority for Mozilla, compared to its main > goal > > of running Javascript (fast). In truth, the whole thing reminds one of > > Pirate[15] and Cardinal[16]: an attempt to support additional languages > > (Ruby and Python) on a new runtime platform (Parrot / Tamarin) that is > > capalbe, technologically, of running those languages, but is clearly > focused > > on a different target implementation (Perl6 / Javascript 2.0). Still, > Ruby > > running natively on Tamarin could be huge, and not just because of > Ruby's > > current heavy usage for web development.
> > Hope you enjoyed reading all that, and take care,
> I'm sure many of you recall last year's presentation[1] "Ruby: Past,
> Present, Future". It took place almost a full year ago, on June 16th. At the
> time, we noted how several of our main subjects under discussion could
> evolve in different ways. Let us review and reflect on those subjects once
> more.
> First off, let's get one major subject out of the way: the Ruby language
> itself. That hasn't changed much, and not likely that it will. The design is
> solid, or at least solidified. Much as it was a year ago, changes planned
> for Ruby 2.0 are small, incremental; and even of those, the majority count
> as wart-fixers (e.g. less surprising handling of closure scopes). So
> everything we said about Ruby as a language a year ago, is still as true
> today.
> Now for the other major subject of that presentation: implementation. There,
> we have many changes and developments.
> _YARV_ is still looming in the all-too-distant horizon, as predicted a year
> ago. There's a lot of interest in it, following the growing concerns over
> MRI (Mat'z Ruby Implementation,the current 1.8.x implementation everyone's
> using) performance. Just a few days ago there was another wave of
> speculation about Twitter abandoning Rails due to poor performance, and
> they're not the only ones.
> YARV still, however, suffers from the same problems we discussed yesteryear,
> namely: lack of significant improvement over MRI. True, it is
> bytecode-compiled, and yes, it is faster and better than MRI. But not by
> much. Last year, this estimate was mostly a speculation, based on analysis
> of the architecture, but since that time YARV has reached an increasingly
> stable state, and benchmarks are becoming more meaningful. Results, as
> expected, are not exciting. YARV is generally no more than 50% faster than
> MRI[2].
> Ruby needs to run at least several times faster to compete with even just
> some of the faster dynamic languages in its class (Python, PHP, Perl). YARV
> currently doesn't provide that, or anything really close to that, while
> several of those rivals are constantly improving their own VM performance,
> both evolutionary (with small incremental upgrades) and revolutionary (with
> ideas like JIT compilation, partial type declaration / inference etc.)
> _JRuby_, as predicted, has continued its determined, stable progress towards
> a solid, fast (but not incredibly fast) Ruby implementation. At the time, we
> discussed at length how JRuby is evolutionary, rather than revolutionary;
> how it aims at modest goals ("faster than MRI", not "as fast as compiled
> C").
> Very little of what JRuby does is experimental or ground-breaking. While
> this may sound unexciting, it also means there's not much soul-searching or
> basic research involved in the core parts of the project. JRuby has been
> progressing by slow, measured, but solid steps; and indeed, of all the
> projects we've discussed, it's currently in the best shape.
> JRuby is currently a 1.8.x-compatible Ruby implementation. It runs Rails
> well. While it is not generally considered quite as fast as YARV[3] in
> interpreted mode, it's running 1.8.x code, and not the unstable 1.9 version
> of the language. This makes JRuby the fastest viable 1.8.x platform, i.e.
> the best performing Ruby platform out there that's actually viable for
> production right now.
> Consequently, there's growing interest in JRuby as a production Ruby
> platform[4]. This is aided by its natural integration with the JVM, the Java
> libraries, applications and tool-chains. However, a major obstacle also
> stems from JRuby's slow, cautious progress - it's not the revolutionary Ruby
> implementations that users yearn for. Being generally a bit faster than MRI
> is certainly a great achievement for an implementation project, but doesn't
> make it an obvious choice over MRI; if you really care about performance,
> both are pretty slow.
> _Rubinius_ has been through a lot this year, fulfilling at least one
> prediction we made about it: of the major re-implementation efforts, it's
> certainly walking the most interesting, twisted path.
> A thorough survey of the twists and turns Rubinius went through is much
> beyond the scope of this post; for anyone truly interested in Rubinius, the
> recent presentation by Rubinius's lead developer, Evan Phoenix, at the
> Mountain West conference[5] could serve as a good introduction. We'll only
> focus on a few short points.
> Rubinius's original slogan has been "Ruby implemented in Ruby".
> Theoretically and practically, it is possible to build in a dynamic language
> a fast virtual machine to host itself. Smalltalk has already done that with
> the Smalltalk-80 design that dates back to the 80s[6]. Some of these
> implementations are very fast[7] compared to Ruby, while offering closely
> comparable levels of dynamism and flexibility. In fact, one way for Ruby's
> performance problems to end is by following Smalltalk's implementation
> strategies; the languages are similar enough from a performance-analysis
> point of view, to make that very feasible.
> The project has gone through many changes and shifts during the last year.
> Just little more than a month ago, it was decided to completely rewrite one
> of its key parts - the Shotgun virtual machine (and in C++ instead of C).
> While there are many good reasons[8] for the rewrite, it will still delay
> progress.
> Rubinius is arguably still the most interesting Ruby implementation project
> around. JRuby deserves a lot of respect for becoming, slowly but steadily,
> the best currently-viable Ruby implementation. Rubinius definitely has a
> long way just to get to where JRuby is right now. But it has been getting a
> lot of attention and love[9], with several top notch Ruby hackers working on
> it full time.
> _Other development_:
> The above covers the major implementations we discussed last year. Not much
> more is known or can be said about IronRuby; the same concerns we discussed
> last year were about as valid then as they are now.
> Three new up-and-coming implementations that I would like to mention are
> HotRuby[10], IronMonkey[11] and MagLev[12].
> _HotRuby_ and _IronMonkey_ are essentially efforts to run Ruby on ECMAScript
> platforms (ECMAScript is the abstract standard on which both Javascript and
> Actionscript [the Flash programming language] are based).
> HotRuby is essentially a hack: you embed Ruby code in your DOM, which
> HotRuby then extracts and sends to the server for processing by Ruby 1.9
> CGI. The results of the Ruby execution (all done on the server) are received
> at the client as JSON and acted upon by HotRuby. There was a lot of buzz
> about this about a month ago, and I'm not sure why. Notably John Resig
> (jQuery's lead developer) blogged about it[13], and it then got Slashdotted.
> One of the main points in the blog is that the whole setup is faster than
> the same code running locally Ruby 1.8.2, which shouldn't surprise anyone
> familiar with Ruby platforms who knows that 1.9 is significantly faster than
> 1.8.2 for comparable code. So maybe this whole thing was a misunderstanding.
> In any case, it's a nifty AJAX trick.
> IronMonkey is much more interesting, but not a whole lot is currently known
> about it. It's basically an attempt to map Python and Ruby to Tamarin at the
> bytecode level. On principle this could be a huge thing, because Tamarin (an
> OSS ECMAScript VM utilzing state-of-the-art JIT technologies) is extremely
> fast. Via the ActionMonkey[14] project, it's being integrated into
> SpiderMonkey (the Javascript engine of Mozilla/Firefox), so it would be on
> every desktop running Firefox 4, perhaps as soon as late this year.
> Unfortunately, though ActionMonkey is making good progress, it doesn't seem
> like IronMonkey is a major priority for Mozilla, compared to its main goal
> of running Javascript (fast). In truth, the whole thing reminds one of
> Pirate[15] and Cardinal[16]: an attempt to support additional languages
> (Ruby and Python) on a new runtime platform (Parrot / Tamarin) that is
> capalbe, technologically, of running those languages, but is clearly focused
> on a different target implementation (Perl6 / Javascript 2.0). Still, Ruby
> running natively on Tamarin could be huge, and not just because of Ruby's
> current heavy usage for web development.
> Hope you enjoyed reading all that, and take care,
Adam Fine wrote:
> _HotRuby_ and _IronMonkey_ are essentially efforts to run Ruby on ECMAScript
> platforms (ECMAScript is the abstract standard on which both Javascript and
> Actionscript [the Flash programming language] are based).
> HotRuby is essentially a hack: you embed Ruby code in your DOM, which
> HotRuby then extracts and sends to the server for processing by Ruby 1.9
> CGI. The results of the Ruby execution (all done on the server) are received
> at the client as JSON and acted upon by HotRuby. There was a lot of buzz
> about this about a month ago, and I'm not sure why.
You seem to have misunderstood HotRuby. The server side only bytecode
compiles the code.
The bytecode (the JSON data) is then executed by the hotruby "vm" on
the client side. So yes,
the performance is a surprise.
On Tue, May 13, 2008 at 3:30 AM, Vidar Hokstad <vidar.hoks...@gmail.com> wrote:
Hi Vidar,
Thanks for the clarifications about HotRuby. To be honest, I'm still not completely sure what all the buzz was about, since anything that requires an HTTP round-trip to the server for execution of client-side code (and embedded in the client DOM, no less) doesn't seem to me like it would be ultimately practical.
Unless HotRuby could feasibly become standalone at some stage (i.e. not dependent on a YARV CGI and an HTTP rountrip for its client side code execution), then it still seems like a hack, though admittedly a cooler and more elaborate one that it seemed at first glance :)
Will probably check out the source a bit more thoroughly just out of curiosity, but I retain my doubts as to its practically.
On Wed, May 14, 2008 at 4:34 AM, Adam Fine <a...@adamfine.net> wrote: > Hi Vidar,
> Thanks for the clarifications about HotRuby. To be honest, I'm still not > completely sure what all the buzz was about, since anything that requires an > HTTP round-trip to the server for execution of client-side code (and > embedded in the client DOM, no less) doesn't seem to me like it would be > ultimately practical.
You can write some nifty eval-less ruby for a flash app or js app. Check out the demos.
On Wed, May 14, 2008 at 9:53 AM, Aur Saraf <sonofli...@gmail.com> wrote:
> On Wed, May 14, 2008 at 4:34 AM, Adam Fine <a...@adamfine.net> wrote: > > Hi Vidar,
> > Thanks for the clarifications about HotRuby. To be honest, I'm still not > > completely sure what all the buzz was about, since anything that requires > an > > HTTP round-trip to the server for execution of client-side code (and > > embedded in the client DOM, no less) doesn't seem to me like it would be > > ultimately practical.
> You can write some nifty eval-less ruby for a flash app or js app. > Check out the demos.
> -- Aur
-- Shimon Amit Lead Software Developer NeuroTrax Corporation
On Sun, May 18, 2008 at 10:19 PM, Shimon Amit <shimon.a...@gmail.com> wrote: > Israel.rb and Adam Fine's Ruby roundup were mentioned on "This Week in > Ruby". Congrats...
> On Wed, May 14, 2008 at 9:53 AM, Aur Saraf <sonofli...@gmail.com> wrote:
>> On Wed, May 14, 2008 at 4:34 AM, Adam Fine <a...@adamfine.net> wrote: >> > Hi Vidar,
>> > Thanks for the clarifications about HotRuby. To be honest, I'm still not >> > completely sure what all the buzz was about, since anything that >> > requires an >> > HTTP round-trip to the server for execution of client-side code (and >> > embedded in the client DOM, no less) doesn't seem to me like it would be >> > ultimately practical.
>> You can write some nifty eval-less ruby for a flash app or js app. >> Check out the demos.
>> -- Aur
> -- > Shimon Amit > Lead Software Developer > NeuroTrax Corporation
Thanks. Now I feel bad for all the stuff I forgot to put in :-)
So here's a quick wrap up of the things I left out:
1) _Rubinius_ has recently made good progress in running Ruby web development tools. About a week ago it ran Merb[1] for the first time. Merb is a performance-oriented, modular and (on principle) minimalistic framework developed by Ezra Zygmuntowicz and others. Scarcely a week passes, and we're told that Rubinius now runs Rails[2].
While exciting and positive, it should be pointed out that both these achievements are for now mostly hacker-oriented. Merb shows a lot of promise, and the developers are hoping for a 1.0 release later this month[3], but for the foreseeable future its target platform will likely be MRI, not Rubinius . The same is true for Rails; while JRuby offers the advantage of Java/JVM integration, with side benefits including additional deployment options and utilization of Java tools, Rubinius for now does not offer any perceivable advantage over MRI, while being significantly less stable and established.
Still, as we discussed last year, running Rails is a major milestone for any Ruby implementation; it's an ad-hoc test for crossing a major, real world compatibility threshold. As such, it's more significant than many other synthesized tests and benchmarks.
2) _IronMonkey_ will have to wait at least another year. In spite of initial hopes, Firefox 4 (and consequently, the most optimistic ETA for IronMonkey) will not be available in 2008[4]. Mozilla's own release goals ("one major release every year")[5] schedule FF4 for 2009; however, note that FF3 missed its intended release schedule by 6-9 months, so 2009 might be optimistic as well. In addition to those delays, FF4's release date is only a best-case estimate for IronMonkey itself. It's very possible that FF4's SpiderMonkey will not support Ruby when it's first released. While the integration of Tamarin itself (ActionMonkey) into SpiderMonkey is a major goal of FF4, supporting Ruby and Python (IronMonkey) on SpiderMonkey is not. In fact, there's very little recent information about the status of IronMonkey, which might lead to a concern that it's not moving along very rapidly. Anyone who knows more about it is welcome to share.
3) _MagLev_ is a topic I promised to discuss on the main post, and simply forgot, so sorry about that :)
MagLev an interesting and very recent development. The project has been first mentioned only late last month, and very little information has trickled down from development team since then. The team is planning a major unveiling at RailsConf later this month[6], so until then MagLev is being kept under wraps.
What we do know is that MagLev is a core VM - written in C - on top of which Ruby runs, to a large degree as self-hosting: besides a minority of performance critical primitives, most methods would be implemented in Ruby themselves[7]. The attentive reader will immediately notice the similarity between this basic design and that of Rubinius. This is hardly surprising, as the company developing MagLev, GemStone[8], is very much a Smalltalk shop, and as we recall, Rubinius's architecture was inspired by the Smalltalk-80 design. It's interesting how both Rubinius and MagLev are attempts to create a Smalltalk-like/inspired implementation of Ruby, but while Rubinius is mostly developed by Ruby folks, MagLev's parents are a group of Smalltalk experts.
We'll have to see how this plays out. Evan Phoenix, lead developer of Rubinius, already called for cooperation/code-sharing between Rubinius and MagLev, but there's no indication of that happening. MagLev's developers did acknowledge that they were examining and even using some Rubinius-related tools - behchmarks, tests, MSpec[7] - but their manner of mentioning that does not encourage much hope for collaboration. Also, it's not clear which license MagLev would be released under. With GemStone being very much a commercial entity, the license might be too restrictive and harm MagLev's acceptance (it's worth noting that lack of sufficiently free and open implementations has been a major cause for Smalltalk's failure to gain acceptance in the nineties).
On the other hand, it's very easy to get excited by this development. Many of the most significant performance improvements possible for a Ruby platform - such as SendSites and Polymorphic Inline Caches - were first implemented in Smalltalk platforms. Rubinius (surprise! ;) is the only other Ruby implementation seriously looking into those, but (at least to the best of my knowledge) non of its developers has much experience implementing such techniques for production system in the real world. GemStone, on the other hand, very likely has such experience among its developers. Yet from what has been related so far, GemStone appears to be lowering performance expectations, focusing on scalability instead[7]. Indeed, regardless of raw VM performance, the architecture and potential scalability of the full system as described[10] could be very attractive.
To sum up for now, I would still be very cautious about an implementation that neither released any code, nor committed itself to any sort of license yet. May 30th may leave us wiser, or disappointed :-)
OK, here's a wrap-up of the RailsConf MagLev presentation[1] aftermath, focusing on the reactions and postmortem analysis of it.
First of all, anyone who read Avi's description of GemStone itself[2] and the InfoQ interview about MagLev[3] would have known most of the hardcore technical details presented at the conference.
Most of the new information that wasn't already present in the above sources, was a confirmation of the analysis based on them. Yes, MagLev looks to be faster than MRI, as well as to offer a very robust scalability solution (through distributed object-sharing) right of the box. And yes, sadly, it does look like the license for that would be commercially oriented, and that MagLev would be the least free of all the Ruby implementations we discussed. That was to be expected of GemStone, being a commercial entity, but now Avi confirmed[4] it: "The Ruby source will be released. The C source code for the VM most likely will remain closed". It's really important to contrast this with the other implementations - Rubinius, JRuby, MRI, YARV, pretty much any of the discussed above. All of them are completely open source, with no closed parts at all.
About the implementation itself: some numbers were thrown around at the presentation, most of them pretty exciting[4]. Quite a few people, some of them highly respected, reacted enthusiastically to those figures[5]. Others were more skeptical[6].
My take on this is that Mr. Nutter is correct to be doubtful of the figures so far shown. With all due respect and esteem to Avi and the GemStone team, Nutter is absolutely right in that you can't see MagLev's code, and can't even run it compiled on your machine right now, so none of those numbers should be taken as facts that represent anything meaningful.
I do not However share Nutter's deep skepticism about the viability of MagLev. His critical post[6] hints disbelief at the very possibility that an implementation so efficient could be concocted in these very few months.
Any discussion of MagLev would for now be clouded by sheer lack of information and the fog-of-hype, but speculating abstractly - lacking any concrete, verifiable technical data - it should be noted that MagLev has taken what in my opinion is the shortest path to a fast, reliable Ruby implementation.
The MagLev project essentially took a working, reliable, fast, mature Smalltalk platform, and modified it to run Ruby - a language similar to Smalltalk in terms of implementation requirements. Ruby execution thus benefits from literally decades of work research, and implementation of stable and efficient Smalltalk platforms, including extensive field testing in some most demanding applications[4].
Such approach should be able - in theory :) - to yield better results faster than the other approaches: building such a platform from scratch (Rubinius) or fitting Ruby on top of a VM that was designed to run a language with very different implementation requirements (JRuby).
To sum up, I do believe that MagLev could, on principle, become a very attractive platform, in a very short span of time. Right now, it's still only a promise. The license would likely be a thorn, and the lot of us, spoiled for years by completely free and open implementations, may not particularly enjoy basing our production setups on compiled executable, without having their source at hand.
If the most optimistic promises of the MagLev development team do realize, Rubyists will likely disregard some of the less savory aspects of a semi-closed license, and use MagLev to create impressive Ruby and Rails applications. If the reality behind the hype turns out to be less than that, a choice to use MagLev would be less obvious. We should hopefully have some more complete performance and compatibility figures quite soon[7].
Personally I hope that GemStone would disclose the full source of the implementation, while opting to protect their commercial interests via some other legal limitations, for example restrictions of the option to fork. Alas, GemStone is a commercial entity, and convincing it to reveal profit-critical code could be very difficult. But in any case, for better and worse, we're living in exciting times :)
