> That's their mistake, right there... No it's not. It's exactly what I want, at least. > When you're upgrading software, you presumably want a better versio

> That's their mistake, right there... No it's not. It's exactly what I want, at least. > When you're upgrading software, you presumably want a better version. Sure... > You can't have something better without changing it. It's a logical contradiction. No, that makes no sense. When I upgrade the rust compiler, I might want it to compile programs faster. I might want its borrow checker to be smarter so that it accepts more valid programs than it did before. I might want to have some new language features (like if-let chaining or GATs). What I absolutely do not want is to have to change the code in my programs so that it can be successfully compiled by the new version of the compiler. Yes, certainly there are some times in the lifecycle of a piece of software that there's an improvement that requires a breaking change, but you believe is important and necessary, so you bite the bullet and do it. But you burn user goodwill every time you do that (maybe not your goodwill, but most people are not like you in this regard), and create work for people that they would probably prefer not to do. You also create fragmentation, because people aren't going to upgrade their new stuff to the new version all at the same time, and some people may never upgrade. All of this has costs, and deciding never to make breaking changes (or at least keep them to the absolute bare minimum) is a reasonable choice in the face of those costs. Maybe it's not the choice you personally would have made, but it doesn't mean it's a mistake. They just value a different set of things than you do, in a completely reasonable way.