my understanding is that rubinius is production ready (and "first class") software today. If they could offer a real performance improvement over MRI 1.9 they would be more compelling.
Rubinius is also a much more compelling environment to develop the Ruby language in, but they just don't support Windows and all the 1.9 changes yet.
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>
This rant seems misplaced. Rubinius adopted a test driven approach for testing Ruby compatibility because Ruby doesn't have a spec, merely a reference implementation. The spec is being worked on, but the fact that it doesn't exist has more to do with Matz and Ruby's culture than Rubinius. Further, your other objections also appear to be rooted in a misunderstanding of Ruby's culture. The fact that there are lots of choices in the Ruby's ecosystem is what Ruby is about. Hell, choice is built right into Ruby with its inheritance model. Python is the opposite, and I'm guessing that's what your background is in.
I'm not sure not if software development questions should be solved with a reference to "Ruby's culture". Wouldn't "what works best" be a better criteria?
I've done more Ruby than Python altogether. It's true that I am no longer doing Ruby - mostly because it is too slow for anything beyond a fairly simple web platform (I would welcome an improvement in Ruby performance).
I would argue that the time spent on the tests could instead be spent on an actual spec.
Did you stop programming in Ruby before 1.9.1? Most common performance issues were fixed in that release. If you need something faster than 1.9.1, you probably should be dropping down to C anyway.
The thing is; C# and Java are also fast enough for an adequate desktop GUI. But they're horrible to program in.
Ruby and Python are still in about the same category of slowness even with pypy's success. I'm doubtful of Python desktop apps but I know they are out-there.
PyPy had head start of almost 4 years. I remember when Rubinius was started, people talked about how self-hosting dynamic language environments have been a failure and they sited PyPy as an example after Millions in funding from European Union.
All rubinius really needs is a non-overlapping set of bugs with MRI and JRuby. That would give it a niche to springboard from. I've been hammering all three with a project which is heavily threaded, and heavily socketed. These are both classic problem areas for MRI, and I've been cranking out JRuby bug reports as well. If rubinius got it right, then we'd be using it instead, but it's not quite there yet.
