That’s what I meant by some exceptions. This one took five minutes to fix. I agree they should have been more careful here, specifically because it was such an easy fix, it wasn’t worth the breakage. It’s the only release I can even remember since 1.0 that I actually had to do fixes for; it truly is rare.
(Also a lot of projects that broke that day would not be broken today, because if there was a lock file, it was updated, and if there wasn’t, the new version with the fix would be selected. Only projects that had that specific dependency on time in their lock file broke.)
Sure. I'm less of a language purist and more of an app / infrastructure developer. [*] I manage projects where I have to plan for how many engineers I will need to staff projects 1, 2, 5 and 10 years in the future. I tend to work in a mature industries (with the exception where I worked for Mozilla and Linden Lab.) We have a vested interest in not throwing away our investment in the technical process. For better or worse, that often means maintaining code-bases for more than a couple of decades.
If I compare the historical stability of C++ with Rust, I find Rust lacking. As I mentioned before, I like the language, but I can't recommend using it because of churn. Python has the same problem. There are features of the Python language I appreciate, but it doesn't matter because, like Rust, I'm going to wait for a decade to see if there are breaking changes to the language. If not, I'll consider it.
I am not saying your baby is ugly. I'm saying your baby is growing but I need a fully-grown thing right now.
Edit: I may have been less obvious about why using a language whose definition changes every several months is bad for code-bases that want a multi-decade lifetime. Consider Python. You get a new, incompatible version of Python every year (yes, 3.X is MUCH, MUCH better than 2.X, but there's still no guarantee there won't be breaking changes.) You only get security updates for three (?) versions back. 3.9, which released in 2020 is currently unsupported. Python purists will point out you can run Python 3.9 apps in a properly configured venv, but that's not the point. The point is I would like to use my application in an environment that is supported. Not only supported by the "official" project, but also by third parties. I unfortunately inherited a project where someone decided to stuff some Python 3.6 code in an AWS Lambda. Had I not worked evenings and weekends to update the then-unsupported open-source software to 3.9, it would have broken when Amazon removed support for 3.6.
And yes, I understand I am describing a problem with a Python project and not a Rust project. That's because I haven't used Rust for mission-critical projects because after dealing with the hassle of updating Python code every year, I don't want to have to update the Rust code myself or try to find people skilled enough to understand that the version of Rust they learned is not the current version of Rust.
Go for a decade without breaking changes and then we'll talk.
[*] Not exactly true, my inner pedant comes out when people talk about Lisp.
I fully agree with you that stability is important, but I do think that you're letting your Python experience color what you think of Rust here. Python takes backwards compatibility less seriously than Rust, and it shows. Rust simply does not churn at the same rate as Python does.
There has already been a decade of Rust with roughly the same level of breaking changes as C++. The issue talked about above is roughly the same as, for example, how gcc can't upgrade to C++20 without a patch: https://gcc.gnu.org/pipermail/gcc-patches/2025-November/7007...
That patch is tiny. Fixing the breakage talked about above was not even changing code, it was running `cargo update -p time`. And it was a notable bit of breakage because even that level of breakage was exceptional in Rust land.
As a practical example, Meta has > 1 million lines of code in their monorepo, and last I heard, they update to each new release within a week of it coming out, and the person who does that update reports that 99% of the time, it's simply updating the version, no changes needed.
> The Facebook monorepo's Rust compiler has been updated promptly every 6 weeks for more than 7 years and 54 Rust releases, usually within 2 weeks of the upstream release.
> I estimate it's about ½ hour per 1 million lines, on average.
(Also a lot of projects that broke that day would not be broken today, because if there was a lock file, it was updated, and if there wasn’t, the new version with the fix would be selected. Only projects that had that specific dependency on time in their lock file broke.)