> It's not the sort of thing that's easy to prove empirically one way or the other
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.
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.