MRI Developers Don't Use RubySpec and It's Hurting Ruby (opens in new tab)

Brian has been paid to work on Rubinius and RubySpec full time for at least 6 years.

Every time I've tried to use it, it's either been unstable (segfaults are fun) or orders of magnitude slower than MRI.

It's a promising project, but as far as "no GIL, true concurrency, mature GC" implementations go, JRuby delivers the goods.

Edit: For kicks, I'm trying to boot my primary app with RBX right now. RTLK threw some "id for nil" exceptions due to some initializer stuff, so I disabled that, and now, trying to run my test suite, after 2 minutes of sitting there doing who-knows-what, it finally attempts to boot my app and dies with a "Missing constant" error despite the fact that I put in debug code to ensure that the file containing said module is a) loaded, b) executing properly, and c) that said constant actually exists in the module tree.

This code boots and runs just fine under MRI 1.9, 2.0, 2.1, and JRuby 1.7. I might be able to get it running with some more work and explicit load path management, but I'm off to a party for now, so I'll poke at it a bit when I get back.

When you see the same behavior repeated consistently over 10 years, it doesn't matter if it's done consciously (what you call "malice") or as an unconscious habit ("indifference"), the effect is what matters and the intent is the same. The Groovy 2.4 release candidate was released a few days ago and announced on the personal blog of the project manager, but not on the Groovy community mailing list, a consistent behavior which started about year ago. Also a year ago, he launched a weekly mailout newsletter he controls about Groovy separate from the Codehaus repository or the backing company Pivotal Inc, soliciting for subscribers. It all looks like a clear attempt to take over from the other developers involved in building the Groovy codebase. I listed plenty of previous examples of such behavior by these project managers going back 10 years that's harmed the ecosystem, probably irrepairably, and I hope Ruby doesn't go down the same path.

See, iirc, Matz years ago specifically said "fork Ruby". He wants lots of different versions which I feel to some extent means diverging from a formal spec, and then occasionally maybe coming back to it.

Why is it unreasonable to expect the RubySpec dev to do additional work, but reasonable to expect additional work from the MRI devs to comply with RubySpec?

I get that "the implementation is the standard" is frustrating for people who want to make an alternate implementation, but why should that obligate the original developers to accept some third party's definition of what their project should be?

Throwing away a project that is clearly working is depressing. can't Heroku/GitHub/37 signals or someone sponsor a week of dev time to automate a system that runs the suite on latest?

It's just such a better outcome, nobody needs to change workflows its just that information gets reported upstream earlier in a much more useful time.

RS needs work contribution from each Ruby to make it sustainable.

It would also show leadership from MRI to encourage a semi-independent Ruby self-test framework that can run on any Rubyish interpreter. (Granted RS has RBX bias, but it would show leadership to coordinate common infrastructure.)

Since RS exists, seems like a good idea to go with that for full up integration testing, but each Ruby should still unit test it's own, low-level bits. (Is MRI doing that at least?)

It's essentially regression testing. Rubyspec specs out the behaviour of Ruby according to what MRI implements, so any failure is a change in behaviour from the initial implementation. Most of the time this is undesirable/unintentional.

At least the bugs are documented. Ruby bugs just are, theres nothing confirming them.

Java bugs need to stay there because if they were fixed then it would be a backward incompatible change.

Maybe this doesn't work for the library ecosystem (standard libraries being where modules go to die), but the language and VM specs are very well designed.

The problem with reading too much into that comment is that the issue being commented on involves setting up an entire "design process" for ruby, including councils and voting and this and that.

It's troublesome to conflate the bulk of that proposal with the reception of RubySpec itself. It may be that some of the Ruby folks would've been receptive to a more limited proposal like "all released versions of Ruby should pass RubySpec", but we don't live in the universe where that happened.

Even then, telling a group of language developers that they should commit tests into what is effectively your "pet project" is a big ask.

Matz: community members can deprive of the power of the dictator, when he apparently loose his ability to make rational decision. After deprivation, the community will make up new rules, hopefully flexible ones. I don't want that situation, but the day will come sooner of later

I think that's a very disappointing point of view, and I say that as a someone who used Ruby in the past. In light of this I can say it will not be my go-to language in the future.

I feel like after a certain point of community uptake, a project surpasses any single developer and becomes a part of that community in and of itself. I understand wanting to maintain control of your pet project, but for community projects I feel like there should be community control. That said, you should have the freedom and the right to do whatever you want with your pet project. Maybe the solution is for the community to fork so they can make the changes they see fit.

Given the way the MRI devs and Matz in particular have responded, perhaps it's time for the community to fork Ruby if they don't like the way Matz insists on remaining the dictator. It's his project and he can do what he wants with it, but we don't have to use it.

That's an absolutely terrifying attitude from a language developer....

They could always have their own fork/branch for upcoming releases of Ruby. It's not like the spec has to freeze the language.

The Ruby devs also doesn't use any libraries I wrote, and that's okay.

Why is RubySpec the special sauce that is so special that the devs not using it is horrible?