I encountered Rust sometime around 2010. I was working a couple of blocks away from Mozilla's Mountain View office and would often overhear people talking about it at Dana Street Coffee Roasting. A couple years later I was working at Mozilla trying to unf*ck their TLS and libpkix implementations. The team rocked, but management sucked. The best part about it is I kept bumping into Brendan Eich and having great conversations about Lisp. I can't remember if P. C. Walton worked there, but several occasions he was in the office and gave me a VERY good, VERY succinct description of the language.
I wrote a fair amount of Rust code in 2012, none of it on a real project like servo. All of it just code to try to understand what the language was trying to make easy. None of that code compiles any more. (Or enough of it fails that I stopped looking at it.)
It's not so much a "critique" as it is a confirmation that when the crustaceans tell you the language definition isn't finished yet, believe them. I like the feel of Rust much more than C/C++, but I have C code I wrote in 1982 that still compiles and does what you think it should do. C++ code from 1990 still seems to compile. I have Rust code from 2014 that won't even compile.
Rust is a cool language and I hope it eventually settles down enough to be considered for "real" projects. I've done a little bit of Ada in the last year and I really, really want something better. But... reverse in-compatibility is a deal-breaker for some corners of the commercial world.
And yes, I know that (like Python) you can build an environment that lets you continue to compile old code with old compilers and some old code with new compilers. But the projects I'm talking about have life-times measured in decades. 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.
I'm not saying Rust is ugly. In fact, I really like some aspects of the language. And post 1.0 is MUCH better than pre 1.0. But if we could go for a few years without breaking changes that would be nice.
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.
> Rust is a cool language and I hope it eventually settles down enough to be considered for "real" projects.
I keep seeing folks with this "when will Rust be ready" sentiment and it feels a bit dated to me at this point.
At my last job we built machine control software for farm equipment (embedded Linux, call it firmware if you like). The kind of thing that would have been in C or C++ not long ago. Worked great, Rust itself was never the issue. Code from the very first versions continued to work with no problems over years of feature additions, bugfixes, rewriting, edition upgrades, etc.
The job before that, my team wrote a large library of 3D geometry analysis algorithms code that powered some fun and novel CAD manufacturing tools. In Rust. Worked great. It was fast enough, and crucially, we could run it against user-provided data without feeling like we were going to get owned by some buffer overrun. 10 years earlier it 100% would have been in C or C++ and I would have been terrified to throw externally generated user data at it. We were able to do what we needed to do and it served real paying users. What more do you need?
Rust is everywhere. It's in the browser. It's in databases. It's in container/VM runtimes. It's in networking code. It's in firmware. It's in the OS. It's in application code. It's in cryptography. It's in Android. Rust is all over the place.
The only other thing I can think of with a similar combined breadth and depth of deployment to Rust on "real" projects (other than C/C++) is Java.
If I needed something to both work and be maintainable by somebody in 2055, Rust is one of the few things I'd bother to put on the list, alongside C, C++, Java, Python, and Javascript.
I've been writing Rust professionally and personally since at least 2018 and this has never happened to me.
There are plenty of real criticisms one can make about Rust (I've made and will continue to make plenty) but I think your argument would be more compelling if you updated your experience with the present-day Rust toolchain. The Rust project takes stability very seriously.
What you've written at the end there is a critique of Rust in 2012, pointing out that it's not a stable language, which, it isn't, as reflected in its versioning, in 2012.
But a few years later, in 2015, Rust 1.0 shipped. So the stability really firms up from there.
I happen to have in front of me the first commit of the first modestly sized piece of software I wrote in Rust in April 2021. Which compiles today just fine and works exactly as it did when it was written, on this brand new Rust toolchain.
I am aware that Rust 1.0 shipped. I am also aware that every year breaking changes in the language occur. It is 2025, it should not have taken this long to "settle down."
What are you claiming constitutes a "breaking change in the language" ?
Sibling comments talk about a 2024 stdlib change which broke some people because they had written code which depends upon an inference and with a new enough stdlib that inference is now ambiguous so the compiler requires that you disambiguate or your code doesn't compile with the newer library.
So, that's not a breaking change in the language. It's annoying, and ideally shouldn't have happened, but in contrast the two languages you praised (C and C++) have in the last ten years made real breaking changes to their actual language and as expected the same people who insist Rust isn't "stable" shrug off the extra work from that as No Big Deal.
As someone who wrote C for decades and now writes Rust instead it's very striking how much worse the "bit rot" is in reality for C.
I'll definitely say that. It's my biggest problem with the language. Type variable declaration lists, pub keyword instead of export lists, macros instead of functors, out-of-line method declaration, special keywords and symbols all over the place that could have just been built-in type constructors, module accessor is the horrible ::, which synergies with a weird decision to nest modules extensively so that code is even noisier.
Rust is a very ugly language to me. Ugly enough that while I like many aspects of its semantic design, I will never use it personally. I would rate it to be about as ugly as Ada, just for different reasons.
Sure. You can call anything ugly. I got in trouble with Walton because I said the borrow checker should be an external tool for C++. With the exception of Lisp, which is $DEITY's own language, all languages have problems. There are aspects of Rust that I like more than C++ (traits vs. classes, for instance.)
The main difference here is I won't down-vote you because you say you don't like Rust.
I think Rust has a lot of nice things about it, semantically. I think sepples is extremely ugly too. I didn't downvote you though, I don't even know how to do that on HN.
>Rust is a cool language and I hope it eventually settles down enough to be considered for "real" projects. I've done a little bit of Ada in the last year and I really, really want something better. But... reverse in-compatibility is a deal-breaker for some corners of the commercial world.
Critical loadbearing chunks of AWS, Cloudflare, Azure and Google are built on it. It's in both the Windows & Linux kernels, shipped on billions of devices, processing probably tens or hundreds of exabytes of data every day. It's running on satellites in space and in production cars. Respectfully, you don't know what you're talking about.
I wrote a fair amount of Rust code in 2012, none of it on a real project like servo. All of it just code to try to understand what the language was trying to make easy. None of that code compiles any more. (Or enough of it fails that I stopped looking at it.)
It's not so much a "critique" as it is a confirmation that when the crustaceans tell you the language definition isn't finished yet, believe them. I like the feel of Rust much more than C/C++, but I have C code I wrote in 1982 that still compiles and does what you think it should do. C++ code from 1990 still seems to compile. I have Rust code from 2014 that won't even compile.
Rust is a cool language and I hope it eventually settles down enough to be considered for "real" projects. I've done a little bit of Ada in the last year and I really, really want something better. But... reverse in-compatibility is a deal-breaker for some corners of the commercial world.
And yes, I know that (like Python) you can build an environment that lets you continue to compile old code with old compilers and some old code with new compilers. But the projects I'm talking about have life-times measured in decades. 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.
I'm not saying Rust is ugly. In fact, I really like some aspects of the language. And post 1.0 is MUCH better than pre 1.0. But if we could go for a few years without breaking changes that would be nice.