The limits of Rust, or why you should probably not follow Amazon and Cloudflare

Lots of tortured logic in this post.

1. You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust.

2. Rust ranks lower on the most used languages list because it's newer than Java, Python, C, and all of the others higher on the list.

3. You don't need to use async Rust. If you do, I disagree that it's as hard as this is implying, but I would agree that it's not as easy as writing sync code.

4. Rust projects don't decay like this is saying. Rust has editions and you can stay on an older edition until you're ready to port it forward. My experience with jumping to a new Rust edition has been easy across all projects so far. It's funny that they argue that adding new features to the language leads to unmanageable complexity, because the very next topic argues that the standard library doesn't have enough features.

5. If you want a batteries-included standard library I agree that you should pick Python or Go instead.

Most of the blog is an ad for the author's book. I was hoping this post had some substance but I think they chose the title first to attract clicks for the book ad and then tried really hard to find some content for the article second.

> Between January 2020 and May 2026 Rust has seen 54 releases, which amounts to 7500 lines of changelog. > During the same period, there was 12 Go releases, 12 Node.js releases (but only 2 LTS) and 5 Python releases.

Some corrections:

Rust saw 54 (I assume that's correct, I didn't recount) minor releases, with a few minor breaking changes. If we only count editions there were 2 releases, but again those don't break backwards compatibility.

Python saw 5 major releases, each breaking backwards compatibility. Counting all releases they had 132.

Node has an LTS every year. There were 6 LTS versions in the last 6 years. Those releases also included major breaking changes.

Go had no new major version, like rust it's only made minor changes.

So going by the author's own evaluation, rust and go are considerably better for project decay.

> For example, I just looked at the dependencies of a small project I'm working on, and we have 5+ (!) different crypto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto

ring is explicitly an experiment, not suitable for use. My guess is the author looked at their Cargo.lock to determine what duplicated dependencies they have.

For the uninitiated, rust libraries can have optional dependencies that only get included under certain conditions. A common pattern is for a library to support multiple underlying implementations, such as different crypto libraries. For instance rustls has both ring and aws-lc-rs as optional dependencies, meaning that both get included in the Cargo.lock file when resolving dependencies. That doesn't mean that both are actually being used.

A common thread I see in this, and other articles of its kind, is that rarely do they come out and say what kind of project they are working on, leaving the headline to sound generically applicable. I can make some guesses, given the emphasis on async, that they contrast with Go, and the mention of systems programming as an exception. But after enough of these, one would get the impression that Rust is primarily a backend language, competing with other backend languages, that happens to also be good for systems. I'm not sure that is even the use case driving corporate adoption.

It's a rehash of a bunch of old misconceptions. I thought we've buried these when people got actual experience with Rust.

The dumbest one is counting changelog lines. Have you even read them? These days most of them are "obscure libstd function is now allowed in const contexts".

The regular Rust releases include compiler improvements, libstd evolution, and build system tweaks. Nobody's saying C keeps changing because LLVM has a long changelog or CMake added a new feature.

Is async in Rust really this bad? Last time I used Rust was before that existed. I know it's a pain in Python because they bolted it on way after, but in JS it's a breeze because everything standardized on promises early.

This is a bizarre article, and it kind of reminds me of the concept that the only truly good software is the software you've never used.

This gets so old. Rust is a programming language. It does some things really well, some things less so. It isn't a panacea, it's a tool. People can use it because they like it, right-tool-for-the-job or not. People can hate it, hating a programming language is one of the most benign things to hate in the whole world. "Language-ist" is a world I never want to live in.

Feels like there are some people who love rust, and some people who hate rust, and most everyone else doesn't give a shit. Everyone is right and everyone is wrong, depending on who you ask.

Can't we just go back to the emacs vs vi debate? Is that the itch people are trying to scratch?

Weird post. One could pick any language OP recommends over Rust and find just as many if not more reasons not to use it.

I don't have a problem with this post, in fact I think it fully redeems any criticism by describing the stronger use cases for the language.

Takeaways:

If picking an arbitrary language to learn, if you are building small-to-medium scale things that require async, rust is not the first thing to reach for.

The stdlib and the package ecosystem is a mess.

---

Use if:

If you need gigascale performance and have the resources to learn it and deal with the complexity of async.

If you are writing performant global OS libraries.

If you are writing IoT and want something with more protection than C.

Nobody has ever seen or heard Wesley Wiser talk. Supposedly he's the rust compiler team lead. I claim he's an NSA front end. Prove me wrong.

There is no reproducible build of the official rustc binary. They claim they're using a modified version of LLVM.

I am moving my projects to Cangjie, I no longer trust _any_ American piece of software.