[aneth]

I find this kind of performance regression and the blasé response extremely frustrating and disappointing. What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications? This should be fixed in a quick patch to 1.9.2. There are tens of thousands of developers wasting oodles of man-hours frustrated with this. It's bad for Ruby and bad for Rails.

Why is this not the #1 priority for the MRI team?

[patio11]

What could the MRI team be working on that's more important than fixing a bug that quadruples startup time for the most popular Ruby applications?

Step 1: Learn to speak Japanese. Step 2: Express that the startup speed of a project that, IIRC, none of them use and that doesn't pay the bills at their day jobs is Really Really Important To White People and that anything which compromises its utility -- which should be checked exhaustively at every release -- should block shipping.

I use Rails, and love Rails, but back home Rails is not yet the core Ruby use case, not by a long shot. Rails has peculiar needs with regards to typical Ruby applications, and a certain portion of the developer community feels that people who write themselves peculiar needs can write their own solutions to them. (i.e. "If they're going to run tests every few seconds and load a thousand files every time it runs... why is poor performance our problem again?")

Apologies for being a wee bit snippy but variations on this discussion have come up before.

[aneth]

By extension, Rails is built on a house of cards - a language team that does not intend to support it, and doesn't care if they cause a majority of their international users a great deal of pain. That would be, as I said before, disappointing and frustrating.

While the MRI team benefits enormously from the international success of Ruby that is largely attributable to Rails, you are right that they are not technically obligated to promptly fix egregious performance regressions. A certain portion of the developer community might feel that it is irresponsible not to support your user base.

[tptacek]

In open source, nobody is entitled to someone else's time and energy. But that's what the word "irresponsible" implies. So, I think you should choose your words more carefully.

As regards the technical problems you're talking about, switch Rubies (I'm a fan of JRuby), or fork MRI.

[aneth]

> In open source, nobody is entitled to someone else's time and energy. But that's what the word "irresponsible" implies. So, I think you should choose your words more carefully.

My words are chosen pretty carefully. Irresponsible implies just that - irresponsible. Taken to its extreme it would be irresponsible for Matz or Linus to suddenly retire from their projects without a trace. Nobody is entitled to have them continue to work on these projects unless they have a business engagement ("open source" has nothing to do with it.) That doesn't make it ok to abandon people who have come to depend on them, who have made them successful, and who have supported them. There are responsible and irresponsible ways to leave a project.

Case in point: _why left an awesome legacy, but screwed a number of people over by disappearing. People have reasons for behaving irresponsibly sometimes, it can be forgiven, and it doesn't mean they are bad people - but that doesn't make it any less irresponsible.

Even your employer is not entitled to have you finish projects you start before quitting, or to have you cooperate in knowledge transfer when you leave - you could quit at any time and provide the minimal contractually required information. Responsible? No.

So yes, the stewards of open source project do have some responsibility to their user base. "Fork it" is the standard, poorly thought through, open source geek answer. It is far more beneficial for everyone to work within the community and voice concerns than it is to fracture the code base. Additionally, there are many layers of software all of which no one is an expert in, and forks introduce their own management headaches. I for one would not be comfortable supporting a fork - I depend on the MRI team for that. We all depend on each other, and anyone claiming they have no responsibility to their user base should let their users know they feel this way so that the users can choose a different library or platform.

[Andys]

Because the #1 priority is to make programming, not loading rails, enjoyable. And there can't be two #1 priorities.

[robryan]

Without knowing anything about the core ruby developers, it's possible most of them are detached from current real world ruby applications with heavy weight frameworks?

[cageface]

It's amusing that Rails is now considered a heavy framework. I remember writing my first Rails app with Rails 0.8. It was a tremendous breath of fresh air then. Seven years later it's the bloated incumbent.

[rawsyntax]

there's always merb 1.1

[plastics]

It's also possible, that real world Ruby applications are - in Japan - generally not written using Rails.

[burke]

Agreed. This is why I really, really hope Rubinius manages to become "worth it" soon (or at least JRuby). The MRI core team, Tenderlove excluded, seem to give approximately zero shits about Rails.

[davidk0101]

Ruby is much more than Rails and I think it's a little sad that a large portion of the developer population has no idea that Ruby exists outside of Rails.

[Vitaly]

i find it a little sad that the core people find it appropriate to ignore needs of a framework that brought the language from the obscurity it "enjoyed" for years to the front lines where it is now.

[plastics]

Ruby was popular in Japan long before Rails.

[davidk0101]

Your revisionist history is another thing that makes me angry. Ruby and Python were getting popular long before Rails and Django came on the scene so before you go running your mouth about core people ignoring the needs of people you should think long and hard about subverting the needs of an entire community just so you can develop another web app.

[smackfu]

Is there really anything in Rails that needs an updated version of Ruby? I know people love to upgrade but what is wrong with just pegging Rails to a lower version, possibly forking it to get any killer bug fixes.

[rimantas]

How does that compare to, say, loading Java application stack? How much of total application lifecycle does loading time take? This is not to say, that no fix needed, just that it is possible that impact is much less important.