Rust achieved 1.0 in 2015, three years after you wrote that code in 2012. Stability wasn't guaranteed until then. Afterwards, it has been. Code from 2015 still compiles today. It's no surprise that 2014 code doesn't compile, as it came before those suggestions.
> I hope it eventually settles down enough to be considered for "real" projects.
Rust is being deployed for real projects at pretty much every major tech company at this point, and is used on the critical path of real infrastructure.
> Will rustc in 2055 be able to compile a program written today? It doesn't seem to be on the top of minds of most of the Rust community.
This has been a very strong focus of the Rust project for a long time; the reason you saw so much breakage from 2010-2015 was to make sure that it was in the state that we'd be okay with making it stable, and then the track record from 2015 to now has been excellent. There have been a few exceptions, but they've generally been quite small, and needed for soundness fixes.
_Some_ code from 2015 still compiles today. Quite a lot of code from January 2024 won't compile today.
Turns out that in practice, the promise not to break code in the past isn't that strong, exceptions that break most of the ecosystem are "Acceptable", and the rust developers response is "Sucks for you, you'll just have to update". See:
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.
> I hope it eventually settles down enough to be considered for "real" projects.
Rust is being deployed for real projects at pretty much every major tech company at this point, and is used on the critical path of real infrastructure.
> Will rustc in 2055 be able to compile a program written today? It doesn't seem to be on the top of minds of most of the Rust community.
This has been a very strong focus of the Rust project for a long time; the reason you saw so much breakage from 2010-2015 was to make sure that it was in the state that we'd be okay with making it stable, and then the track record from 2015 to now has been excellent. There have been a few exceptions, but they've generally been quite small, and needed for soundness fixes.