I would say that Rubinius needs to be
significantly faster than MRI
and production ready to be successful. Otherwise, it's an "option" and having "lots of interesting options" at the level of your language is actually detriment to your development process. As someone said, you want your setup to be "as boring as possible" so you can concentrate on your application code instead.
Having "lots of exciting choices" in your web server, your database, your object server, your language implementation, or monitor size just says your time will be sucked from real work.
<almost a flame> I have been tempted, in the past, to wildly claim that if you compare Rubinius' relative failure compared to PyPy, Rubinius is kind of a poster-child of Test Driven Development's failure. IE, languages need semi-formal specs, not tests that claims they are a standard (no amount of testing can prove two implementation equivalent). </almost a flame>
<CAVEAT>But listening to the PyPy folks describe their process, I realize this stuff is uber-hard and I'd just like to hear what a real compiler developer would say about this. </CAVEAT>
