Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MRI Developers Don't Use RubySpec and It's Hurting Ruby

rubini.us

Post reply on HN
Print view View original

71–80 of 118 posts

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#71

Post by sanderjd »

vinceguidry wrote: post #65
sanderjd wrote: post #59

Earlier quoted context omitted.

In my experience, executable specs are much more useful than their non-executable brethren. They prove their own correctness, and can't gloss over important details.

> They prove their own correctness, and can't gloss over important details. They most certainly don't, do either of those things. You can still have incorrect, incomplete specs even with an executable test suite. You only get those properties through constant work. The idea behind TDD is to do that as you develop the application, but even then you're not automatically saved from incorrectness and incompleteness. The…

It's interesting reading your comment that purports to disagree with mine, while feeling that it instead agrees... I think perhaps the confusion is that I misread your comment that I replied to as suggesting that you can't have an executable spec, rather than (as I now think you meant) as merely claiming that an implementation can't be its own spec, which I definitely agree with.

I think something like RubySpec is fantastic, and that it's really too bad that, perhaps only because of personality conflicts with the maintainer, it hasn't been successful at standardizing behavior across ruby implementations.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#72

Post by rmoriz »

nateberkopec wrote: post #22

Rubyspec is a great project for all the reasons Brian outlines. However, it's also a failure - in part, due to Brian and his attitude towards contributors. See this twitter conversation: https://twitter.com/the_zenspider/status/547527644535726080 He's been grinding on Rubyspec for years, bless him, but I think there's a reason why he was unable to rally the community behind his effort, both in terms of gathering more…

>However, it's also a failure - in part, due to Brian and his attitude towards contributors.

Looks like he seems to be burned out - maybe he just wants something in return for his time investment e.g. a paid job or some other gratification in return for his work.

Btdt - you put a lot of work into something, people/companies start benefit from it but they don't return anything important (monetary compensation is not a bad thing -it allows one to pay the bills/go on holiday/get a life).

We've seen this "pattern" a lot in the OSS world, but saying a different attitude would "fix everything" is a lie. We (as in the Ruby community) need to crowd-fund independent developers who are not paid by companies for their OSS contribution IMHO.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#73

Post by cheald »

btown wrote: post #55
nateberkopec wrote: post #22

Rubyspec is a great project for all the reasons Brian outlines. However, it's also a failure - in part, due to Brian and his attitude towards contributors. See this twitter conversation: https://twitter.com/the_zenspider/status/547527644535726080 He's been grinding on Rubyspec for years, bless him, but I think there's a reason why he was unable to rally the community behind his effort, both in terms of gathering more…

> JRuby, currently the only non-MRI ruby implementation that you can seriously consider for production use Are there concrete shortcomings when using Rubinius in production, or is it just not battle-tested yet?

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.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#74

Post by headius »

rmoriz wrote: post #72
nateberkopec wrote: post #22

Rubyspec is a great project for all the reasons Brian outlines. However, it's also a failure - in part, due to Brian and his attitude towards contributors. See this twitter conversation: https://twitter.com/the_zenspider/status/547527644535726080 He's been grinding on Rubyspec for years, bless him, but I think there's a reason why he was unable to rally the community behind his effort, both in terms of gathering more…

>However, it's also a failure - in part, due to Brian and his attitude towards contributors. Looks like he seems to be burned out - maybe he just wants something in return for his time investment e.g. a paid job or some other gratification in return for his work. Btdt - you put a lot of work into something, people/companies start benefit from it but they don't return anything important (monetary compensation is not a…

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

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#75

Post by sitkack »

sanderjd wrote: post #59
vinceguidry wrote: post #53

Earlier quoted context omitted.

You can't call code a spec. Saying you're defining Ruby by coding it just means you don't have a spec.

In my experience, executable specs are much more useful than their non-executable brethren. They prove their own correctness, and can't gloss over important details.

They dont define anything, they are tautological.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#76

Post by rmoriz »

headius wrote: post #74
rmoriz wrote: post #72

Earlier quoted context omitted.

>However, it's also a failure - in part, due to Brian and his attitude towards contributors. Looks like he seems to be burned out - maybe he just wants something in return for his time investment e.g. a paid job or some other gratification in return for his work. Btdt - you put a lot of work into something, people/companies start benefit from it but they don't return anything important (monetary compensation is not a…

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

oh - didn't know that. Okay that makes a hughe difference IMHO.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#77

Post by Sivart13 »

drivingmenuts wrote: post #18
hartator wrote: post #10

Has Matz stated the reasons they are not using RubySpec? Knowing him, I can't really believe he has chosen to ignore RubySpec without good reasons.

https://bugs.ruby-lang.org/issues/7549#note-2 Apparently, he and some of the key devs don't like design by committee or much in the way of bureaucracy.

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.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#78

Post by headius »

masklinn wrote: post #14
danielweber wrote: post #11

Earlier quoted context omitted.

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?

> Why is RubySpec the special sauce that is so special that the devs not using it is horrible? Assuming TFA isn't actively lying[0]: because it fixes the issues outlined which allow (amongst other things) cross-implementation and cross-version uses, because it tests behaviours not tested by the MRI suite anyway and because it's there as an extensive test suite for the language. Oh, and because according to TFA it fou…

I wouldn't say TFA is lying but it is presenting only part of the truth. MRI does have an actively developed test suite, which they run in CI and which we use to test compatibility in JRuby. MRI has contributed to RubySpec in the past and many contributors I know stopped (like I did) for nontechnical reasons. They are not ignoring it, but it is a hard project to collaborate on given the attitudes of the project lead that should be evident in this post.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#79

Post by foobarian »

dankohn1 wrote: post #57
fat0wl wrote: post #30

Earlier quoted context omitted.

yes I don't want to get into a flamewar either, but I am an ex-RoR dev and since switching to enterprise Java I hear almost nothing about it largely due to enormously widespread acceptance of Spring (JavaEE is even re-gaining some traction). Long story short (and hope my facts are right! not swearing by this, was just some googling...), I had to optimize some old code for an RoR client I freelance for and wanted to a…

You are ignoring a decade of history in declaring Rails to be "dangerous for enterprise use". The reality is that Rails apps are used in thousands of enterprises around the world, as well as in "web-scale" businesses like Github, Airbnb, and Groupon. However, Rails (and specifically ActiveRecord) has a very specific design philosophy (see http://david.heinemeierhansson.com/2012/rails-is-omakase.htm... ) which does no…

The "enterprise" I work at uses a dozen little RoR apps to put a quick and dirty UI on some DB tables so analysts/sales/support folks can interact with the data.

The main problem with Ruby in this kind of setting is that these internal tools are extremely hard to maintain because of backwards compatibility issues--which there are plenty due to lack of spec, organic language development etc. The effort to upgrade the Ruby version is much greater than doing incremental hacks to support some half-day feature, so the codebase stays pinned to the 2007 Ruby release, we can't use new gems, have to live with old bugs or missing features, etc. And with every new incremental change the project gets harder to upgrade.

The Java ecosystem has done a lot better in this regard. Scala is not very good either, we have had a couple Scala projects with version lock-in effect as well.

Re: MRI Developers Don't Use RubySpec and It's Hurting Ruby

#80

Post by vidarh »

MBCook wrote: post #44
danielweber wrote: post #11

Earlier quoted context omitted.

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?

That's basically how I read this. It seems that Ruby is specified de facto by what MRI does. Reading this blog post it sounds like the developer of RubySpec did this: 1. Decided Ruby needed more formal specification 2. Made their own formal specification 3. Kept telling the core developers to use it 4. Is giving up after years of the core developers not bending to the way he thinks that Ruby should work The whole thi…

The problem with "MRI as spec" is that nobody really knows how the language is defined.

E.g. large parts of the 1.8.x series behaved differently from what most people thought it did in terms of the bootstrapping of inheritance of core classes. I wrote a blog post about Ruby behaviour based on introspecting the 1.8.6 interpreter that some people insisted was wrong because it worked differently than intended. Yet the behaviour persisted for years until it silently changed at some point (I don't know which revision).

In that case it was no big deal since the reason the real behaviour was pretty much unknown was that nobody depended on the behaviour, but from what I've seen this is fairly common with MRI.

As a "spec" it is one of the most unstable environments I've worked with. Though I love Ruby the language, MRI is a problem as the default implementation and atrocious as a "spec".

I frankly hope one of the other implementations gains enough traction to force the core team to the "negotiating table" over a proper specification.

Post reply on HN