It's not the sort of thing that's easy to prove empirically one way or the other, but I get the feeling (despite being a heavy user and fan of Ruby) that other languages take that guarantee more seriously. It's a tradeoff: by not spending much effort on backwards compatibility, they can spend more time developing "cool new stuff". Users get more new stuff faster, at the expense of having to worry more about upgrades breaking things.

On the contrary. People on real production environments encounter the lack of compatibility guarantee all the time. Bundler is a way to guarantee compatibility regardless of actual future release compatibility.

> other languages take that guarantee more seriously

In general this seems to be true, but they do so on a best-effort basis. None of them provide perfect guarantee; that is, if there's some kind of law that would allow you to sue them $1000000 every time they break compatibility you would be VERY rich by now.

For example many people who use Python in production environments use virtualenv to guarantee compatibility. Virtualenv has a similar function to Bundler. Java people just tend to vendor specific versions of dependencies and don't rely on shared dependencies at all.

Even high-profile libraries that have extremely well-defined compatibility guarantees - such as GTK - tend to mess up from time to time. A few years ago they made a change in GObject. If you upgraded GTK then that would break the GNOME login manager, rendering your desktop useless (this problem was later fixed).

Breaking compatibility because of human error happens all the time, and often in unexpected ways. Bundler and similar tools provide protection against that in return for a bunch of other disadvantages. The point is you can't see compatibility as an either-perfect-or-nonexistant thing.

It's more than just a feeling. They certainly do.

But: Those languages are there. They live! Perl 5, for example, is there. It has not gone anywhere. Its community would love for you to use it. The fact that some people sometimes decide to use other things tells us something about the value of backwards compatibility in uncertain times.

My impression is that Ruby does change uncomfortably quickly, but not so quickly as its problem domains are changing. The rate of change of our software ecosystems is a symptom, not a cause. My god, the things that have happened in the last decade. Cheap virtual machines in the cloud. Widespread use of distributed version control. Client-side web apps. Mobile applications. NeXT cubes in your pocket for $250.

Java, which seems to take it fairly seriously, is way more popular than Ruby is.

I agree that the world changes quickly, but disagree that you need to radically change stuff all the time.

For instance, in Rails, they went from <%= to <% back to <%= for forms. To me as an end user, that is completely useless churn.

Like I've said, I like Ruby and am mostly happy with it, but there's a tendency to rush off after the 'latest new thing!' that at times I view as counterproductive.

As for the Rails <%= thing, where did you get the idea from that they went from <%= to <% and back to <%=? Did all of this happen within the same release minor release cycle? Rails has a strong compatibility policy for minor releases and only tend to break things between different minor releases.

The tag thing in Rails has happened over time, not in the same release cycle, but still it's annoying.

Yes, I am. Just because they have a policy in place doesn't mean that I lose my right to air my opinions.

The point with the <% thing is that it feels a bit too much like gratuitous code churn to me. <%= is what you use to output something, and you do want to output a form, so <%= is what they should have stuck with from the beginning.

I could be off, but I think rails 1.2 did that.