It appears brixen is very frustrated; what he has written in this post and in the link skade gave reveals that he has come to the conclusion that 8 years of effort he put into RubySpec were never valued in some way – whether this is true or not doesn’t matter, this is just his point of view. Trying to get at him with objective arguments won’t work in that state, he first has to cool down. Entirely abandoning RubySpec seems a short-circuit reaction as a result of his frustration, and I think once some time has elapsed he will revise the decision to a certain degree. Maybe he will just ask others to take over the leadership and restrict himself to only few commits. Which might, as he doesn’t seem to be recognised as a nice person, actually help the RubySpec.
As for Rubinius itself, I can’t predict where it is going. If brixen doesn’t master his frustration he is indeed going to fork the language as skade suggested. Unless he comes up with some very unique features this will bring Rubinius into some little edge position where it will most likely die unrecognised, which I’d find really sad as I like the idea of a Ruby implementation that mostly is written in Ruby itself. Though on this end one probably has to consider how other people involved into Rubinius think. It might be that he suddenly walks a lonely path then.
What I find a bit disappointing is that he talks about multiple conversations with Matz and other core commiters, but doesn’t let us know what was actually said. He just states that RubySpec wasn’t seen as useful, but I can’t imagine Matz and others just rejecting his work outright. It would have been interesting to know why actually the core team didn’t judge RubySpec to be useful.
I’ve not followed Rubinius development closely, but the prime reason I used it was real, parallel threading without having to have a Java runtime lying around. As far as I know, MRI still maintains the Global Interpreter Lock (GIL). But maybe this might get triggered in the future also.
[Comment removed by author]
The top comment to that response seems to indicate that this is far from being ‘settled’ in the community at large…
Please note the surprising silence of other Rubinius people towards Brians outbursts and the heavy opposition he gets from other Ruby implementors, mostly Charles: http://twitter.com/headius
Brian was never one for constructive collaboration and didn’t create a very friendly environment in the RubySpec project. See, for example: https://twitter.com/the_zenspider/status/547527644535726080 (all the people he speaks to in that discussion are Ruby implementors in some capacity).
One of the reason I see RubySpec was never accepted into ruby-core in it’s current state is that this would slow down development by magnitudes: Every change to Ruby semantics (even if they are considered internal) would need to be run past run past Brian, and then fought out with such a person.
Also, Rubinius was also well known for using the gaps in their own spec to implement extensions that later broke due to MRI deciding differently. For example,
foo = def bar
Was “nil” for a long while. Rubinius decided to return the Method object instead. Later, MRI decided to just return the method symbol, which lead to some complaints.
This shows what the current angle of RubySpec is: RubySpec is Brians Ruby, MRI is Matz Ruby. If you understand that, it’s suddenly very clear why MRI doesn’t use RubySpec (officially).
Inofficially, quite some MRI implementers do use RubySpec to check for things, they just don’t aim for compatibility.
My current reading is that Rubinius is struggling to keep their product up after being funded for many years to build a beautiful, but never finished project. With JRuby finally making a push for feature parity with Ruby 2.2.0 and does bring additional features to the table (Java compatibility!). Other Interpreters and compilers filling up others spaces like embedded and mobile. Open attacks against MRI from the Rubinius side are getting more and more common, but there is still something missing from their side: a proper replacement. MRI is making lots of ground yearly lately, 2.2.0 does have many worthwhile improvements and compatibility in practice is okay.
FWIW, I removed Rubinius from all my test suites, because keeping up with their problems and holes was a huge pain, which kind of counters their point of MRI being a cost factor. It is, but be a saint first, before you complain.
It is no surprise that “future of Ruby”-talks rarely mention Rubinius. It has become a community oddity.
Anyways, I think we will see a language fork soon. I’m also sure it will be a dead end for Rubinius.
Some additional comments:
MRI does run Rubyspec, but a fork, not Brians RubySpec: https://github.com/nurse/rubyspec
You can see CI results here: http://rubyci.org/
All I’m saying is this: you have to understand a few years of interpersonal and inter-organizational politics to understand what’s going on here. It’s been brewing for a long, long time.
I care about everyone that makes every Ruby, but this was really the only outcome.
That’s a shame. In contrast, here’s some positive news (from 5 months ago) on attempting to spec a similarly implementation-defined language:
Ruby is ISO specified for quite a while now.
Still, to be actually usable, your implementation needs some much more then follow the spec, for example implement the native interface. If there were JPHP following that spec, it still couldn’t run C-implemented libraries from std or the library ecosystem. That means reimplementations for other unspecified things are necessary.
That has basically been the work of the JRuby team for years: Lobbying to people to use a proper FFI instead of the MRI C-API, reimplement some parts of the C-parts of stdlib in Java, properly, help projects like Nokogiri (Rubys main XML parser) to ship a JRuby implementation…. And they got very far with it.
Don’t be fooled by “it has an outward spec”. The ecosystem is still the practice you have to work all day with.