RubySpec is dead, long live RubySpec!

gistfile1.md

Last night, Brian Shirai unilaterally "ended" the RubySpec project, a sub-project of Rubinius (the alternative Ruby implementation which Brian was paid to work on full-time from 2007 to 2013). The blog post describing his reasons for "ending" the project led to a big discussion on Hacker News.

When a single, competing Ruby implementation tells that you its test suite is the One True Way, you should be skeptical. Charles Nutter, Ruby core committer and JRuby head honcho, spent a lot of time last night on Twitter talking to people about what this decision means. He's probably too busy and certainly too nice of a guy to write about what is a political issue in the Ruby community, so I'm going to do it on behalf of all the new or intermediate Rubyists out there that are confused by Brian's decision and what it means for us as a community.

Brian's Mission Is Good

A reference specification is a noble idea. Java has one, and it's probably a net positive for the language. If Ruby could magically have a complete implementation-agnostic language spec, today, I think everyone would be very happy with that outcome. I want to be clear that very few people in the Ruby community disagree with this idea in principle.

Practically speaking, all implementations of Ruby have absolutely benefited from RubySpec. JRuby runs RubySpec alongside the MRI suite. Many smaller implementations such as Topaz also use RubySpec. MRI uses RubySpec, most notably in the run-up to 1.9.2 (as Brian pointed out), but core members still use it today, even if it isn't officially part of the project (since all you need to do is run RubySpec against Ruby head).

Anyone that spends eight years of their life, for any reason, working in our community is someone we want to have around.

Brian's Technical Reasons Are Mostly Wrong

A lot of Brian's post is trying to spread fear, uncertainty, and doubt. Here's the statements of fact that I take issue with:

• Ruby has an ISO spec. Characterizing Ruby as a completely "spec-less" language would be incorrect. There's been an effort at an ISO spec for Ruby. Admittedly, it's not finished or perfect, and has mostly been the effort of a small group of Japanese academics. But it's there, and Matz has expressed that an ISO standard is what he sees as the way forward for a formal specification of Ruby.
• MRI's test suite has much more coverage now. It definitely used to be pretty bad, as Brian writes. The road from 1.8.7 to 1.9.3 was extremely, extremely painful for everyone, paved with bugs and minor versions. But to characterize the MRI suite as being inadequate for Ruby as a language seems inaccurate. JRuby runs almost 6000 tests and over 1 million assertions directly from the MRI suite. Does that sound like a test suite that is completely unusable to other Ruby implementations?
• MRI has used RubySpec, and some members still do. RubySpec's "minimum viable contribution" to Ruby has, and will continue to be, "does MRI pass RubySpec?". This doesn't take any official sanction or additional contribution from anyone - just run MRI against RubySpec, and open pull requests and issues when you find problems.
• A lot of MRI's process happens in Japanese. Matz, and a good chunk of the Ruby core team, is Japanese and runs on Japan time. While most of the discussion online happens in English, it can sometimes feel like there's "no process" around Ruby because a lot of discussion happens in Japanese or even in meatspace in Japan.
• Other languages use reference implementations. The absence of a formal specification, while not ideal, is not some dooming fate for a language. Python has got along just fine without one for quite a while.
• One bug doesn't change a lot. Brian pointed out that Ruby 2.2 fails a RubySpec and segfaults. This is obviously not intended - Ruby isn't supposed to segfault when running pure Ruby, ever. But one bug from a competing Ruby implementation (again, RubySpec is basically just Rubinius' test suite made re-usable) does not mean that MRI's suite is useless. All Ruby implementations have valid bug issues with MRI - and they open issues and PRs on MRI to deal with it. In fact, Brian refused to do this with this latest segfault (though he says he's opened tickets in the past). Charles Nutter had to open an bug report for him.
• Ugly tests are ugly tests, not useless ones. A lot of Brian's arguments come down to aesthetics - he thinks a lot of the MRI tests are nonsensical (some definitely are), the suite is incomplete (whose isn't?), it sets up test state inconsistently, combines too much behavior into a single test, and sometimes specify behavior that is undefined. All of these issues are valid, and they can all be fixed with a pull request. Brian's solution, instead, seems to be to throw the baby out with the bathwater and use (his) RubySpec instead.

Brian's Methods Are Controversial

I have to say that this is the tough part of this blog. Shit-slinging about personal slights and disagreements doesn't help move the issue forward, and I think the discussion about the ending of RubySpec has been very civil so far. However, there is a long history of non-technical reasons as to why Brian, Rubinius and RubySpec have been controversial in the Ruby community, and Ruby developers who haven't had time to follow the issue would be done a disservice if we all pretended that no one has personal issues with Brian Shirai.

• Brian doesn't value the contributions others have made to RubySpec. Brian doesn't think that the other committers to RubySpec have made meaningful contributions to the project. This attitude does not grow a community around an open-source project. It's actively hostile towards new contributors. It's not hard to imagine why RubySpec is struggling for contributions with a project lead that says things like:
  • "write specs in way that conforms to the standards I set"
  • "you have a few PRs, that's nice"
  • "I've had to fix a ton of crap committed by many people"
  • "ensure they abide by my quality requirements"
  • "a few PRs is not contributing"
• Brian wants more control over Ruby. For a long time, Brian has basically wanted a larger role in the decisionmaking and design process of Ruby, which, de facto, is Matz's sole privilege. This is where we get into the politics of RubySpec. Make no mistake, by making RubySpec the project (not "the test suite") "official" and requiring MRI developers to contribute to it, Brian is gaining control of the way Ruby is designed. I think it should be made clear that making RubySpec "official" in the way Brian wants is something he stands to gain from. Brian's issues with MRI's rejection of RubySpec are not technical, but political. This is OK (all large open source projects require some politicking to run), but Brian isn't making his aims and motivations clear in his blog post.
• Brian's primary responsibility is to Rubinius, not Ruby. Brian has said as much. In my opinion, he's also shown this in his actions in the past. Rubinius, his competing Ruby implementation, has shown that it's willing to break compatibility with MRI where it sees it is right to do so, or to "improve" the language in ways Brian and the Rubinius team thinks is right. This is, obviously, his perogative, but I think it's important to understand that Brian's vision of Ruby is obviously different than a lot of the core team, and Rubinius reflects this differing vision. Brian sees MRI as needing to get with his program, not the other way around.

You Can't Stop The Signal

In the end, RubySpec is open source software. It's sort of preposterous to end a project like this - Brian admits he made this decision unilaterally, and in the face of disagreement from his peers and contributors to RubySpec. Brian can't really "end" RubySpec so much as "leave the project". And it's a sad thing, I think - anyone that devotes this much of their lives to Ruby in any way is someone I wish would stay in the community. But Brian has clearly chosen to leave the mainstream of Ruby - and both MRI and Rubinius will suffer for it.

I think this whole episode carries a very poignant lesson about the way open source software is run. Brian seems to think that disagreements in OSS should be resolved with large, sweeping changes and formal governance - RubySpec and the proposed Ruby design process are concrete examples of this opinion. However, many successful projects, like Ruby and Rails, have operated with a much more piecemeal approach: incremental change, one pull request at a time.

RubySpec continues to exist, as code. Running RubySpec as a separate test suite, externally, and simply reporting the bugs back to MRI has always been and will continue to be useful. In fact, it seems like something good might come out of this episode after all - Charles Nutter (again, an MRI core committer) has discussed being open to including RubySpec in the MRI repo as a separate test suite, something which Brian has, to my knowledge, never proposed (I would guess since it would relinquish the control of the project to Matz and the Ruby core team).

Unfortunately, drive-by trolls and new Ruby developers will inevitably see this as "another sign Ruby is dying!!1". The reality is that Ruby has been doing quite well without RubySpec officially driving the design process. Ruby 2.2 is faster and more memory-efficient than ever, and a single failing RubySpec with a segfault doesn't change that.

So my advice to Ruby developers is this - let's put Ruby in Schrodinger's box. It's dead, it's alive, who cares? What I know is that Ruby is still a language that I love writing, and I still build awesome things with it. None of that has changed. And I don't think it will.

EDIT: Removed some unfair assertions about Rubinius' production-readiness, and made my point about the MRI suite's usefulness more clear.

Context: I actively work on Rubinius (for almost 2 years now), use it in
production for serious internet business. Take my views as you wish, but
consider I have at least some decent experience on the matters (instead of just
making them up).

Ruby has an ISO spec. Characterizing Ruby as a completely "spec-less" language
would be incorrect. There's been an effort at an ISO spec for Ruby.

From what I remember the ISO spec is largely based on Ruby 1.8 and does not
discuss critical features such as encodings. The ISO spec is also not freely
available (costing $200).

As a result of this the ISO specification is fairly useless when one wants to
support newer Ruby features such as encodings, keyword arguments, etc. Or
when one simply can't afford to buy it.

MRI's test suite is pretty good now. It definitely used to be pretty bad, as
Brian writes.

Having had my fair share of interacting with the MRI test suite, I can guarantee
you it's not "pretty good". One of many examples:

https://github.com/ruby/ruby/blob/316210b80bd0afff27be5925dbf5521982bebe93/test/ruby/test_m17n.rb#L1521

vs

https://github.com/rubyspec/rubyspec/blob/91ce9f65493a18acc401dc7ded0e79e0226a03c6/core/string/scrub_spec.rb

It took me and Charles over a month (if my memory serves me right) to implement
String#scrub for Rubinius/JRuby exactly due to this problem. The basic
documentation of the method was in the end more useful than the tests.

Is it better than before? Sure, but it's still a long way from the quality of
RubySpec or even the quality of specs you typically see in Gems.

MRI has used RubySpec, and some members still do. RubySpec's "minimum viable
contribution"

People running RubySpec once in a while is completely useless when they don't
provide feedback on it, work on the specs itself, etc. This is like saying
you're contributing to the Linux kernel because you're just using it.

Other languages use reference implementations. The absence of a formal
specification, while not ideal, is not some dooming fate for a language.
Python has got along just fine without one for quite a while.

Python has the PEP system which helps tremendously. The argument of "X works for
others" does nothing to discredit any criticism on this. Just because somebody
else does something doesn't mean it works for others.

One bug doesn't change a lot. Brian pointed out that Ruby 2.2 fails a RubySpec
and segfaults.

The bug is just a specific example. We've encountered plenty of cases in the
past that could've been dealt with a lot faster if everybody (MRI, JRuby, Rbx,
etc) were equally actively involved. Some examples:

• https://bugs.ruby-lang.org/issues/10561
• https://bugs.ruby-lang.org/issues/10016
• https://bugs.ruby-lang.org/issues/9898

Ugly tests are ugly tests, not useless ones.

They very much are useless for anybody who's not familiar with the intention,
either due to the lack of a proper description or something else.

In general I suggest you actually spend some time digging into any of the above,
in particular working with the MRI test suite. Especially before making the
above arguments.

Brian doesn't value the contributions others have made to RubySpec. Brian
doesn't think that the other committers to RubySpec have made meaningful
contributions to the project.

Lets disect this for a moment to see what this refers to. We'll take a few of
the more common contributors in Ruby and see how much they've done for RubySpec
recently.

JRuby:

• headius: last
  spec was added December 2nd this year, before that the last spec was in
  October 2013.
• enebo: last
  commit on Jan 20, 2011
• chrisseaton:
  no commits yet in RubySpec itself, although he was working on several things
  related to that, so props for that (I mean it)
• eregon: perhaps
  the only JRuby developer that more actively works on RubySpec, although recent
  changes were more maintenance related

Opal:

• elia: mainly
  maintenance related to get Opal running, which is appreciated although it
  doesn't strictly help Ruby as a whole (as "mean" as that might sound)

Now lets look at some Rubinius developers:

• brixen: this
  should be obvious
• yorickpeterse:
  mainly a bunch of CAPI stuff and smaller specs. I spend most time on the issue
  tracker. A lot of the commits are from syncing Rbx <-> RubySpec.

If we limit Github's contribution graph to the last year we'll get the
following:
https://github.com/rubyspec/rubyspec/graphs/contributors?from=2014-01-01&to=2015-01-01&type=c.

The top 3 are all Rubinius developers, with eregon clocking in at #4. Meanwhile
the people that are most angry about RubySpec being pulled are at the very
bottom of the list.

From this it's rather clear that at least when it comes to working on RubySpec's
codebase, there's not a lot happening from non Rubinius developers. This is
exactly what Brian means with the lack of contributions, how changes matter (or
not) in the grand scale of things, etc.

He's also absolutely right about having to fix specs of others and he's not the
only one (I've done so in the past as well). People seem to get annoyed when we
demand quality, but it's the state of MRI's test suite that we actively want to
avoid, which can only be done by expecting people to actually write good specs.

Brian wants more control over Ruby. For a long time, Brian has basically
wanted a larger role in the decisionmaking and design process of Ruby, which,
de facto, is Matz's sole privilege. This is where we get into the politics of
RubySpec.

This section is such bullshit I'm not even sure where you are getting this from.
The whole point was not for Brian, or any other individual for that matter, to
have more control over Ruby. Instead it's to ensure decisions are made
co-operatively, tested properly, discussed, etc, etc. These are all things that
are extremely important to ensure a good programming languages exists/continue
to exists. It's baffling that one expects businesses to bet millions of dollars
on a language that can't even get this right. Python for example at least has a
step in the right direction.

Brian sees MRI as needing to get with his program, not the other way around.

This is in reference to his attempts to work together (e.g. see the part about
getting RubySpec in the ISO). Given that MRI is outnumbered in terms of projects
using RubySpec (Topaz, Opal, JRuby, Maglev and Rubinius) this isn't really
surprising.

In the end, RubySpec is open source software. It's sort of preposterous to end
a project like this - Brian admits he made this decision unilaterally, and in
the face of disagreement from his peers and contributors to RubySpec

No disagreement has been voiced. Most of those reviewing the article gave
feedback on the article itself but nobody disagreed that I know of. In fact,
I'm fairly sure most agree due to the complexity and energy drain of the
RubySpec project.

Brian can't really "end" RubySpec so much as "leave the project". And it's a
sad thing, I think

He can since he's the primary maintainer. People can of course fork the project
into something different, but then it's RubySpec-something, not RubySpec itself.

But Brian has clearly chosen to leave the mainstream of Ruby - and both MRI
and Rubinius will suffer for it.

By this point I'm getting fed up with the amount of nonsense in this article,
but this is downright insulting. Brian has no interest in leaving Ruby, Rubinius
won't suddenly stop supporting Ruby where possible and Rubinius will anything
but suffer from it. If you are referring to Rubinius X, this is an idea to build
what we think would be "Ruby 10", but Rubinius itself will always continue to
exist.

In fact, it seems like something good might
come out of this episode after all - Charles Nutter (again, an MRI core
committer) has discussed being open to including RubySpec in the MRI repo as a
separate test suite, something which Brian has, to my knowledge, never
proposed (I would guess since it would relinquish the control of the project
to Matz and the Ruby core team).

Charles is but one of many in the MRI core team, his opinion is not the decisive
factor. Numerous attempts have been made in the past to ensure MRI adopts
RubySpec, with little success to date. It was rejected from the ISO spec, it's
not actively included in the development process and not a single contribution
has been made from any MRI developer (except for 1 commit of headius) in the
past year.

JRuby remains the only production-ready alternative implementation (for all of
Brian's blustering, Rubinius remains out of consideration for nontrivial
deployments) and is coming up with some very cool stuff with JRuby 9000.

Bullshit, plenty of people have reported running Rubinius in production just
fine over the last few months. I myself run it in production and save for some
issues with third-party Gems it works perfectly fine. This argument of
"nontrivial deployments" goes to show how little you actually know on the
subject, making this article all the more confusing. In fact, one could argue
that Rubinius deployments are easier due to the support of C extensions instead
of requiring Java/FFI alternatives.

So my advice to Ruby developers is this - let's put Ruby in Schrodinger's box.
It's dead, it's alive, who cares? What I know is that Ruby is still a language
that I love writing, and I still build awesome things with it. None of that
has changed. And I don't think it will.

Open your eyes, businesses are moving away to languages for any number of
reasons. Twitter tried to make Ruby perform well with Kiji in the past, and they
moved away. Others are moving to languages with better concurrency facilities,
more stability, etc. If you think nothing will change it's time to open your
eyes and see the world as she truly is.

I can see that I'm going to spend a good chunk of tomorrow (it's after 0130 local here now) going through Charles Nutter's Twitter discussions that Nate linked to. I've been paying attention to RubySpec for nearly five years now, seen the smoke clouds rising in the distance from the Ruby drama alluded to, and over time become both more convinced that we need something like RubySpec while at the same time increasingly questioning how much RubySpec can accomplish given the technical and other issues involved. I think I've had my attitudes adjusted somewhat, by Brian's action and attempt at explanation, and by Nate's very thoughtful piece here.

---

There's a lot here that I agree with, and not a little in Brian's post that I see as a wake-up call. I agree that It Would Be Very Nice if we had an ISO Standard; however, having seen the politics of that process up close and personal with more than one language, I can understand if Matz and the core team aren't in a rush to make a more comprehensive, post-1.8 ISO spec happen.

I agree with Brian where he suggests what is meant to be interpreted as the need for an implementation-neutral (or at least -independent), canonical set of specs for the language. They should evolve as the language continues to evolve, and can provide invaluable service while still approaching completeness, whatever that means. I too am sceptical about someone with his history with the community being given a, let alone the, leadership role in such an effort. That does not in any way diminish the community's, and industry's, imperative need for such an effort to be undertaken successfully.

We'd be in a much better place to defend ourselves against the keyboard trolls and professional haters that, as Nate said, will jump on this as though it's a gift unicorn showing up in their bedrooms, or at least their news feeds, with a comprehensive, independent set of specs. That's not the best reason to make such specs happen, of course. Our team, like a justifiably huge part of the community, uses MRI (though we're staying with 2.1.5 for now). But the scope and complexity of Ruby 2.2, compared with versions only a couple of years out of date, seem to argue for community organisational change.

Proposal: Keep MRI as the reference implementation of Ruby, and absolutely keep Matz as BDL. But can we all agree that a reference implementation shouldn't be a one-off, but should show others how it's done right? As new features are introduced into MRI Ruby, ask Matz's designated release maintainer to verify that reference specs exist for those new features, in a way that isolates (necessary) implementation dependencies (like the C standard library mentioned by both Brian and Nate). Let's have a consortium, or foundation-type org, take over maintainership of RubySpec or a fork thereof, and steer it towards something that everybody can agree is a Good Thing that isn't threatening because they have as much of a stake in it as anyone else. Get some "community guidelines" with teeth courtesy of "you engage in 'slanderous or duplicitous behaviour', you lose the right to consortium-held IP separate from RubySpec2-the-open-source-system (like trademarks, branding)." Pull a Mozilla, and dare the would-be Brians to push an Iceweaselised "Ruby" onto users who can at least see the difference and, with a bit of searching, understand why it is.

Maybe we'd evolve to something that would make an ISO Standard almost anticlimactic. Maybe the community would eventually decide that they want to hang onto more control over Ruby's destiny than an ISO Standard would give them. Those are battles for another day, if not another decade. For now, there are really only two questions:

What is "Ruby"? And can we prove it in an objective rather than de facto manner?

EDIT: Tpyos.

Yorick: Thanks for taking the time to write such a detailed comment and give the perspective of someone from the Rubinius team. Obviously we disagree on a lot, but I hope this blog didn't give you the idea that we're not "on the same team" and don't have the same goals of making Ruby a better language. I'm sorry that you're insulted that I think this decision represents Rubinius leaving the Ruby mainstream. I still think it does, and I don't find that suggestion insulting. At the same time, I don't think that our disagreements mean that somehow my experience is inadequate or that I have less of an understanding of the issue than you do. I think the tone of your comment is an unfortunate example of why the rest of the Ruby community didn't decide to contribute to RubySpec.

@nateberkopec Ah, the classic tone argument, I should've expected that one. While you might not like my "tone", the argument behind it still holds true. The various claims you've made are false/broken and I showed you exactly why. This will be my last comment as it's a waste of my time trying to explain this to somebody who has already formed an opinion on the matter even when they were never involved in any of the subject (that I know of).

I got to see an early version of Brian Shirai's rant. I'm not necessarily putting my seal of approval on it, but I am very glad that I persuaded him to take out a particular section which was kind of incoherent and unnecessarily personal.

I really wish somebody had done the same thing for Nate Berkopec before he posted this response. Take out the "Brian says this, but he secretly thinks that" stuff and the "Brian is just a dick" stuff, and it's a lot easier to have a conversation.

Likewise, when you've got a gist which purports to clear the air, and it states that nobody uses Rubinius in production, and the first comment is "I use Rubinius in production for serious internet business," that's not what successful attempts at clearing the air ever look like.

By the way, "serious internet business" is my new favorite phrase. And I am definitely sticking with this "Mr. Shirai" and "Mr. Berkopec" thing. I know it must seem weird and stilted, but "normal" in the Ruby community means drama which would barely be appropriate among 13-year-olds. I don't mind being a little different here. If anyone wants to join me in being the weirdo who actually makes an attempt to be polite now and then, you're very welcome to do so.

Anyway, I think Charles Nutter raised some great points on Twitter yesterday (although I'm sure I missed some of them, because it was New Year's Eve). Mr. Shirai's comments in the IRC log definitely looked dysfunctional, but they also looked exhausted. Maybe eight years ago, when the project began, it was a different story?

Maybe not. Either way, I totally agree with Mr. Nutter that folding RubySpec into MRI might be a good solution. But I also totally agree with Mr. Shirai and Mr. Peterse that the code for the MRI tests is not good. I mean they're in Mr. Shirai's rant, and Mr. Peterse linked them in his comment. It's easy to find them, but it's not easy to read them. They are certainly not perfect. And Mr. Shirai also said something about MRI being developed off "trunk," which implies either Subversion or CVS. That's not even modern technology.

MRI remains a huge achievement, to say the least! But when you see how the sausage is made, it's kind of terrifying.

Epic caveat, of course: I'm looking at the MRI tests which Mr. Shirai showed me. Maybe there's tons of simplicity and clarity there and it's just an illusion that there is a mountain of technical debt there, within which lurks baffling but inevitable security risks. If there are better tests that we should be looking at instead, link them up.

Anyway, if Mr. Shirai's management of the RubySpec project was its only obstacle to success, well, the good news is he's abdicated that role. Therefore RubySpec has no more obstacles to its success. Hooray.

Sorry this comment is so long and rambling. Hope somebody gets some use out of it.

Hi Giles!

"Brian says this, but he secretly thinks that" stuff and the "Brian is just a dick" stuff, and it's a lot easier to have a conversation.

I don't think that's fair. I think Brian has a negative attitude towards contributors, I didn't say he's a dick. We're talking about why people haven't contributed to RubySpec - Brian's attitude and demeanor towards contributors is a valid point in this discussion.

Likewise, when you've got a gist which purports to clear the air, and it states that nobody uses Rubinius in production, and the first comment is "I use Rubinius in production for serious internet business," that's not what successful attempts at clearing the air ever look like.

I'm going to remove this assertion. It's probably unfair and doesn't really have anything to do with the issue at hand.

But I also totally agree with Mr. Shirai and Mr. Peterse that the code for the MRI tests is not good. I mean they're in Mr. Shirai's rant, and Mr. Peterse linked them in his comment. It's easy to find them, but it's not easy to read them. They are certainly not perfect. And Mr. Shirai also said something about MRI being developed off "trunk," which implies either Subversion or CVS. That's not even modern technology.

I think I need to reword that bullet. What I mean is that "MRI's tests are much more complete". I agree that they're far from perfect (all of the points Brian raises about the test suites aesthetics and clarity are absolutely valid). From what I understand, Yorick and Brian think that because some (even most!) of MRI's tests are difficult to read and complex means they're useless and need to be rewritten from scrap. I disagree - coverage is coverage, IMO, even when it's not great. Charles (ha!) mentioned on Twitter that he thinks Ruby core moving to git is a possibility for 2015.

Thanks for the comment, Giles.

The elephant in the room that needs addressing is this:

https://github.com/nurse/rubyspec

rubyci runs nurse's version of rubyspec. it even accepts PRs.

So mri team were unable to work with the rubyspec team, were forced to fork rubyspec but have not been backporting specs into the branch.

One VERY constructive way of helping out here is backporting all the missing specs into this branch.

Sam, do you have any knowledge about when that was forked?

the divergence appears to date from April 23, 2013.

@nateberkopec

From what I understand, Yorick and Brian think that because some (even most!) of MRI's tests are difficult to read and complex means they're useless and need to be rewritten from scrap.

There's a risk of overgeneralization here. The word "useless" does appear in Mr. Peterse's comments, but Mr. Shirai's rant uses "inadequate." Certainly similar, but not quite the same.

Also, re "rewritten from scrap," you could pretty easily make the case that some of these tests have already been rewritten from scrap, and have been available in a rewritten-from-scrap state for eight years.

My interpretation was that the RubySpec, JRuby, and Rubinius teams have, over the years, sometimes found it very difficult to use the MRI tests. Mr. Peterse mentioned a specific situation where he and Mr. Nutter found the documentation more useful than the tests.

To me, those tests look like legacy code. I've never seen anybody who wrestled with legacy code and didn't want to just throw it all out and start again clean. This rarely goes well. I've done it successfully, once, but I've failed at it too, and I think the one success story was probably a fluke. It wasn't a gigantic project like Ruby.

Anyway, if you've got clean code and ugly code, and you've built up enough clean code to replace some of the ugly code, I think it's a good idea to do that, but I also think it's a very delicate process.

Also, I think Ruby core moving to git would be awesome.

+1 for having experienced undue difficulty getting contributions pulled into rubyspec.

OTOH - look at the bright side. currently MRI passes nearly all of the tests. Only 48 errrors or failures out of 154,917 expectations. Thanks to rubyspec, many nonworking feature are succinctly exposed. Perhaps consistent bug reports and gentle prodding might help convince the MRI core team to make future releases meet the rubyspecs.

My question is, which fork to use now?

Since I have been mentioned at least twice in regards to the latest rubyspec drama, then I will mention two things:

1. I really disliked submitting to rubyspec; so I stopped figuring working on an implementation which many people derive benefits from was enough to not be criticized.
2. If Brian wants to pull Rubyspec that is his prerogative. Someone can fork it if they want and should if they think it is important. If people look back at the last irc log where I was mentioned you will see I had this same opinion back then as well.

Notice both of these points boil down to the same thing: Don't try and force someone to do something they don't want to. My corollary to this is that people should put energies in OSS towards working things they enjoy. It ends up being a positive multiplier since others get the benefits of your work and you feel good about it.

I know this comment will be unpopular in the Ruby community, but I think it needs to be said:

As a fan of Ruby who has used it with production systems ranging from tens of millions to hundreds of millions of monthly active users, I'd like to politely suggest that the whole discussion is essentially moot until Ruby resolves perf issues. I've ported several apps from Ruby to Node with improvements ranging from 2-10x in simultaneous connection handling and 3-10x improvement in server response times. We abandoned Ruby for reasons similar to Twitter's -- incurable systemic slowness.

Obviously, some of the perf gains I have witnessed have been due to better algorithms and more mature understanding of the required system design at rewrite time, but we also ran a suite of greenfield benchmark tests with Ruby and Node configurations (optimized by a team familiar with production Ruby). Ruby got thoroughly trounced.

I know part of the Ruby philosophy is to favor developer productivity over raw system perf, but that argument flies out the window when developers have to wait frequently for specs to finish running. Ported specs ran in 30 seconds+ on Ruby and less than 3 seconds in Node. OUCH. I wish I could post the spec source. It was a horror show butchering that I'm sure better Ruby devs could have improved on.

Node is also trouncing Ruby handily on developer productivity in another way: Isomorphic code. We can run almost identical code on both the server and the client-side. AFAIK, there isn't a serious movement to use transpiled Ruby -> JS in production, so this advantage is not easily swept away (yet).

As I mentioned, I'm really a fan of Ruby. There are amazing ideas, and the syntax is beautiful, but right now, it just can't hold a candle to Node for large scale / enterprise production, and that makes me sad. I want Ruby to be a serious contender. I'm rooting for the Ruby community.

IMO, this is a much more serious battle than any argument about standard specifications. It's all moot if developers can be more productive using a directly competitive platform -- and right now, they can, and are.

There is no compelling reason for people to switch from Node to Ruby. I'd like to see the Ruby community focus on that instead of infighting over standards that won't mean a thing if Ruby continues to get left in the dust.

Programming language diversity is a great thing, and I'd really like to see Ruby have a chance in this fight. Don't waste your time getting mad at me. I stopped paying attention to Ruby after the 2nd port project because I don't have time to wait around for it. Instead, try to be open to the criticism and fix it.

I wish you all the best. I'm rooting for Ruby!

P.S. If you want to try Node but you hate JS syntax, I've used CoffeScript in large production deploys too. You'll recognize (and appreciate) some of its features.

@gilesbowkett

the divergence appears to date from April 23, 2013.

The actual day is Feb 20, 2013

Also, I think Ruby core moving to git would be awesome.

Use https://github.com/ruby/ruby

Anyway for people who want to write tests for ruby implementation, use simple test framework. Since the ruby implementation is not reliable in this case, the test framework must be simple and reliable. If you use rscec/mspec, you will see a SEGV inside of the test framework.

ericelliott:

That is just a use case for javascript. Many ruby hackers do not need javascript - that is why they can use opal.

Ruby will get faster so it won't be an issue. Guess why mruby was started in the first place? One day it will replace the old ruby, or serve as the base for which to extent into MRI.

@ericelliott Hate to say so, but your post is as off-topic as it can be for this discussion.

Hey YorickPeterse:

"If you are referring to Rubinius X, this is an idea to build what we think would be "Ruby 10", but Rubinius itself will always continue to exist."

So you are actually agreeing that you intend to do SOMETHING else other than Ruby with Rubinius, yes?

I am sorry but Rubinius changed the moment evan was gone. Today's Rubinius is different and so are its goals. The identity of a project changes the moment the key people leave - you can take _why as an example. Shoes nowadays depend on java - in the past it did not. So it is no longer the same. Nor will we see new whycats, that cartoon is gone forever.

Google used to have a "don't do evil" slogan; they abandoned it when they got bigger.

Things change.

Rubinius is already no longer having the same goals as it used to have and it will continue to diversify and change into something ... who knows. The maintainers of Rubinius will decide on that.

But it will definitely no longer be Ruby itself. You are just piggybacking on Ruby while changing Rubinius into something else. You should be more honest about the REAL goals of Rubinius too.

jdickey: "Let's have a consortium, or foundation-type org, take over maintainership of RubySpec or a fork thereof, and steer it towards something that everybody can agree is a Good Thing"

No. Why would this be needed? It seems your personal preference rather than where you actually mention why it would be required. It was not required in the past either. There is this huge flag-waving "omg omg omg we need RubySpec omg omg omg". Well we did not really, and now that it is gone we can all move on.

There is no drama - you just make it want to appear as a drama.

There is also one distinct part I disagree with nate - now I have no particular opinion pro or con with Brian; I have no problem with him at all either. For me Rubinius lost its importance when evan went away. I do know very well that several people don't get along with Brian, that is all fine. But the statement to "unilaterlly end" ... erm ... RubySpec got started by the Rubinius guys, ok? And the license allows you to take over, yes?

So what is the problem THERE please? I concur on several other parts and I don't think Rubinius will be about Ruby in the future either. Theys imply felt that their time on RubySpec was wasted, which is PERFECTLY right for them to want to do so. It is their time, too. So if you really think that RubySpec is so important or awesome, and I personally don't think it is, then you could take it over and then we will see. Otherwise it just seems unfair that you state that Brian "unilaterally closed" it ... want to take it over or what nate? ;)

Hey @shevegan,

Couple of problems with your last post.

• Rubinius will continue to support MRI Ruby semantics
• Rubinius X will be a test bed for different language features but it is a separate project
• Titanius will be the "platform" for creating languages. Rubinius and Rubinius X will use Titanius as their foundation.

This information is available in the posts that Brian put up during the month of December on the Rubinius blog. So, your statement that Rubinius will no longer be Ruby is false. It's unfortunate that these different things all have similar names, so your confusion is understandable or forgivable.

Regarding Evan, yes, the project changed when he left. Not better or worse, just different. I haven't ever seen you in the Rubinius IRC channel; did you have a lot of experience with the project at any point (either pre or post Evan)? What's your last experience with Rubinius on your system running against your code?

Regarding a consortium, it's a good idea. Right now Ruby semantics change from version to version and even from patch level to patch level. It's a moving target that no alternative implementation has been able to hit yet. Unless MRI's development process changes, it will be difficult for any team to ever have perfect compatibility with it. Even mruby (written by Matz himself) isn't compatible with MRI. If Matz can't do it, what chance do the rest of us have?

Rubyspec has been forked. We'll see if the Ruby community actually uses it and improves it. Further, it will be interesting to see if the specs remain of high quality or if it devolves into some of the junk tests that we see in MRI. I have high hopes.

Lastly, the shoes project is alive and well. It's better now than it ever was under _why. It's been refactored so that any GUI lib can be used on the back end. The first target was Java (Swing?) but someone could write for your favorite GUI lib. The code is all Ruby unlike _why's mishmash of Ruby and terrible C (seriously, check out the old C code... it's inscrutable). My point in correcting you about shoes is that projects under new ownership are not automatically worse; a new team can bring new ideas and new enthusiasm (or not). Hopefully the new owners of the forked Rubyspec kick some ass and make it great.

@shevegen,

Ruby the language should and must be separate from Ruby in any particular implementation. This would allow both for innovation and for the business folk (who pay most of our paycheques and bills) to have a far greater degree of confidence in stability and continuity than is presently justified. (The impetus for the current discussion is merely one example of that.) If the language is to be distinct from any individual implementation, then there needs to be some organised "someone" identifiable as responsible for that, and there needs to be an objective means of demonstrating conformity with a given version of the language. Hence, there is a critical need for a follow-on to RubySpec with less of the political wrangling and historical bad blood that surrounds the current project.

Saying "Matz is BDL and MRI is the reference implementation" merely identifies our single points of failure. Matz, as wonderful as he is, is one guy, and things happen to people all the time. MRI is a widely-used implementation, but it's not really organised as a reference implementation, a teaching tool, anymore (if it ever was). YARV supplanting Matz's (original/evolved) implementation and becoming "the new MRI" was just the last nail in that coffin.

Sure, it's open source; we can have fifty different repos with fifty ever-so-slightly-different versions of RubySpec. What does that gain the community beyond confusion and a growing certainty by those outside the inner-circle-of-the-moment that we as a community aren't interested in getting our shit together?

We need to grow up. We need a community that is more than the sum total of our individual egos. We need a language that teams can implement and maintain without worrying that the rug is going to be jerked out from under them, or worrying that they're going to have to spend half their total effort-hours fighting the political fires. I've been in this craft for 35 years and the only community I've seen that's this playground-ego-driven has been the BSD communities, and that's been a huge influence on the growing use and popularity of Linux. Just to make an obvious example.

It's not what I want; I didn't create (for example) rubydrama.com. I would never have even known it existed were it not for Mr Shirai's post; the fact that it does exist, and is as widely known and referenced as your search engine of choice would indicate, should be sobering. People have a tendency to identify with the work and tools that they love; that's part of what keeps us doing this job. Adults learn to work together and, especially, eventually figure out that the world isn't all about them. I don't want to elbow in and take over anything; I'm just trying to prod a piece of the discussion that, having seen similar discussions start and evolve in other communities, I'm convinced is existentially required in ours. You may disagree with me; fine. Make a better proposal, and sell it to the community at large. Threatening to hold your breath until your neck turns blue, or shouting down anyone who dares to voice ideas different than yours, undermines this community; it does not help it.

Projects that mean something should be about more than one person, no matter how talented; that's just the Beer Truck Rule in action. ("What happens if your top three guys get run over by a beer truck while coming back from lunch a week before you ship?") Saying "oh, (this project) doesn't mean anything now that (some early leader) left" is just announcing to the world that either the project is too immature and irrelevant to be taken seriously, or possibly that you are. Very likely, as is the way of the world, a bit of both. I doubt that was your intended effect.

Ruby does "mean something", to us and to a lot of other people. Shouldn't we, collectively and individually, act as though it does, and take our responsibilities more seriously?

Note that I am a very casual user of Ruby, and by no means a 'programmer'... to describe myself that way would be false advertising. Because my interest is of a totally different nature than that of real programmers, by definition I have less of a vested interest, and as such, my observations are just that - observations with no value judgement attached to the conflicting opinions posted here.

It seems to me that the issues raised here are based on unknown and incomplete information:

1. How does Matz feel about other competing implementations of Ruby - has anyone ever asked him? If he doesn't favor them, it's completely natural that he wouldn't want anything to do with anything that makes them easier to establish, as contributing to and using RubySpec would do, and quite aside from any benefits Ruby might derive from doing so.

2. How does Matz feel about the whole performance issue? Perhaps it barely qualifies as a priority for him. If he does care, perhaps he should make clear the boundaries of his concerns and what he proposes to do to address them so that people will have a better sense if Ruby is 'right' for them, and whether some fork or even a new, whole different language is the best choice for them.

As an aside, kudos to Mr. Bowkett for his emphasis on civility. All too often, although certainly not always, insulting behavior is used in an attempt to mask the faults in someone's arguments, or to flat out try and intimidate an opponent. Even when it isn't, kindergarten-style playroom behavior is often a net negative... As a case in point, it's been well documented that Microsoft's no-holds-barred embrace of this kind of culture had deeply corrosive side effects. Just because we have absolute free speech (aside from defamation) -- and should have! -- doesn't mean that there aren't things that shouldn't be said. Gratuitous insults fall into that category.