From where I'm sitting, this isn't to do with the framework much. It's more that DHH has made a coding decision based on an assumption about how the organisation using the framework does its development: specifically in this case that it's forced all its developers to use the same ruby and gems provisioning system. That's valid for 37S, and completely wrong for a whole bunch of other places. DHH then says:
It's imo an anti-pattern to have developers working on the same app use different
tool chains like that. If your organization can't decide on rvm vs rbenv, then
you have deeper problems than what binstubs are checked in to your repository.
and
Second, if you are unable to use the same Ruby manager in production and development,
I feel bad for you. We rely on .rbenv-version to ensure that the same Ruby point
release is used in both places.
Now, say you don't force all your developers through the same toolchain, or you're not using the same Ruby manager in production and development. Given these opinions, how likely is it that at some point there's going to be a Rails design decision based on them which isn't so trivial, and which causes a lot of pain for anyone on the wrong side of them? The fear is that you could be organisationally barred from using Rails for reasons that have been totally irrelevant before now.
These aren't the cut-and-dry truths that DHH is presenting, although I can see the logic in them, and I think this problem has only happened because of binstubs, which are a really bad idea.
Hasn't Rails always been like that? The "Trust us, we know what's best for you" line of thinking. Its part of their marketing, because they sell the "magic" of Rails. It drives people to Rails and it drives people away from Rails. Plus, anyone who uses Rails in production and does not agree with the way the Rails people run things is just asking for trouble. When you choose a framework you dont do so because its popular or nice. You first check the culture behimd the development team and their credos. If they believe in backwards compatibility and you value that, then pick that one. But dont pick something becuase its cool and then argue when the people in charge make decisions that make no sense for you. Its your problem, not theirs. DHH can wake up one day and say that Rails will now be written in Algol. You either re-factor to Algol or jump ship. Either way, you were doomed from the start. Thats why Im always wary of programmers who join into a framework too quickly.
Well, that's the point. We're talking about rails 4 here. It's a mature framework at this point, and yet apparently here is the DFL saying that people who historically have had no problems running Rails are now - without warning - deemed to have made a mistake.
Thats why Im always wary of programmers who join into a framework too quickly.
How long should a framework be given, then? Or is your point that anyone who picked Rails made a mistake precisely because it's an opinionated framework, and they aren't a DHH/37S clone?
Rails culture has always been about change. There is focus on backwards compatibility but its not job #1. If you can't change along with Rails, then you should not use it. DHH can do as he pleases because thats his framework. It powers his business. If he needs to change anything to fit his needs, then he will do so. Thats the culture of Rails.
I use Rails, and its a nice framework. But I'm not a fanboy. Its just another tool for the job. Just like Django, Symfony, Flask, Sinatra, Laravel, Slim, etc.
Now, I'm not getting into a pissing match with you. We are arguiing the same point, just from two different perspectives. I do agree that Rails 4 is mature enough. But the culture is not. And that's what keeps Rails from replacing shitty Enterprise frameworks. A shame because Ruby is fun to write and very powerful.
These aren't the cut-and-dry truths that DHH is presenting, although I can see the logic in them, and I think this problem has only happened because of binstubs, which are a really bad idea.