There are probably more than 50 "decent" virtual machines in production use, many of them open source. Anyone who completes a graduate-level course in language and compiler design should be able to create a decent bytecode-based VM, and should be able to make a good start on a simple JIT.
Here, in no particular order, are the ones I can think of off the top of my head:
The problem is not a lack of VM designs, implementers, or experience. It comes down to two factors:
* Ruby is a weird language, compared to most -- it wasn't so much designed as composed (in the sense of art/music). Normal compilation, optimization, and type-safety rules just don't apply, so even clever VM hackers are sort of left scratching their head when it comes time to optimize or deal with harder problems like serializing closures.
* The Ruby community is deeply bifurcated into two mutually-suspicious subgroups: the Rails users, and everyone else. Rail people hate (or at least mistrust) backwards-incompatible innovation in the language itself, because it breaks Rails, and (at least some of) the other group resents the Rails guys for holding the language back.
If you don't believe me on this second point, look at Ruby 1.9. If 1/10th the energy went into testing and patching new Ruby releases as goes into a minor point-release of Rails, we'd all be running nice, fast, bytecode-compiled Ruby scripts with full Unicode and fiber support. Instead, we're stuck and 1.8.6 for anything "serious", because it's the last release Rails supports well.
Here, in no particular order, are the ones I can think of off the top of my head:
* Tamarin * OpenJDK * Squeak * Parrot * Python * Self * SpiderMonkey * PLT Scheme * CLisp * V8
(...etc., etc.)
The problem is not a lack of VM designs, implementers, or experience. It comes down to two factors:
* Ruby is a weird language, compared to most -- it wasn't so much designed as composed (in the sense of art/music). Normal compilation, optimization, and type-safety rules just don't apply, so even clever VM hackers are sort of left scratching their head when it comes time to optimize or deal with harder problems like serializing closures.
* The Ruby community is deeply bifurcated into two mutually-suspicious subgroups: the Rails users, and everyone else. Rail people hate (or at least mistrust) backwards-incompatible innovation in the language itself, because it breaks Rails, and (at least some of) the other group resents the Rails guys for holding the language back.
If you don't believe me on this second point, look at Ruby 1.9. If 1/10th the energy went into testing and patching new Ruby releases as goes into a minor point-release of Rails, we'd all be running nice, fast, bytecode-compiled Ruby scripts with full Unicode and fiber support. Instead, we're stuck and 1.8.6 for anything "serious", because it's the last release Rails supports well.