Beautiful example how a combination of open source enthusiasm and commercial interest can generate some first class software. There's no way this could have happened without Evan's initial enthusiasm or Engine Yard's support. TBH I can list off dozens of open source projects that are one sponsor away from another level greatness. :P
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.
You can also use jruby now. I'm not trying to diminish rubinius, I hope it works out well and I worked with one of the contributors, but I've been using jruby for a while now and it's great.
This is really great news: I spent some time digging around in the Rubinius JIT in December, and realized that it wasn't going to generate significantly better code until the byte codes were replaced with an intermediate representation that made type checks visible to the optimizer.
In the long run, Ruby implementations will be at least 1 order of magnitude faster than either MRI 1.9 or JRuby. And I'm glad to see that the Rubinius folks are taking the necessary steps to get there.
Also, long ago there was Prothon, which wasn't exacyly python but was very close, and didn't have a GIL. Unfortunately, it seems all source code drops of this disappeared from the earth, though you can still find some mentions e.g. http://blog.ianbicking.org/initial-thoughts-on-prothon.html
I've never been massively keen on the carious implementations of ruby, they're all a bit different and those differences appear to be documented poorly. This is most visible if compared to the python landscape.
I don't have a handle on the Python implementation landscape, but the various Rubies all regularly contribute to rubyspec[0] and report on how they're doing. And with rvm[1] it's incredibly easy to test code across rubies. From where I'm sitting, it seems dead simple to find the differences and how they could affect me.
I appreciate this isn't a great example, as python 2.7 isn't a different implementation (ruby 1.8 -> 1.9 is though), but this has been my experience of the way things are documented language-wise.
I'm afraid that the only explanation I can formulate for your comment is that you are simply unaware of alternative python implementations, because the differences between rubies and pythons are documented approximately evenly.
The Ruby approach is that you should have good enough unit tests to make sure that you can pass everywhere you want. That is also a generally good idea with other dynamic languages, as you get checks that the compiler provides on static languages (like making sure that if you renamed a method, you renamed calls to that method everywhere).
