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.
> 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead.
But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices
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?
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.
In fairness, the post specifically mentions Amazon and Cloudflare, which are using Rust largely for backend stuff (though also for lower-level systems-y stuff, and I think Go is also a favored backend language at Cloudflare). But yes, other large tech companies (Google and Meta come to mind) are using Rust primarily for the lower-level systems-y stuff, where Go isn't an option and the alternative to Rust is C++. These applications are also less likely to need async and so don't have to deal with that set of rough edges.
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.
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.
If your reference is JS or C#, then Rust's async has more friction and annoying details. But Rust is generally harder due to being low-level and picky about memory management and thread-safety details. In a way it's a compliment that Rust's usability even gets compared to GC languages.
If you compare it to hand-rolling state machines in C, or even callbacks in pre-async Rust, then it's an amazing simplification and a very sweet syntax sugar. Especially when you want async code composable, supporting control flow and cancellation.
If you compare it to naive sync Rust while ignoring the extra capabilities that async adds, then async is more complicated and less feature-complete (Streams have more moving parts than Iterators, generic async closures have trickier syntax than generic sync closures, there are scoped threads but no scoped multi-threaded futures, etc). IMHO the difference isn't large and it's reasonable for what you get.
There's also a view that async/await syntax is fundamentally misguided and shouldn't exist at all. From Rust's perspective that's an agree-to-disagree. Rust tried having green threads first (before 1.0) and decided it was too intrusive and magic for a low-level systems language. Rust tried to make do with just threads, callbacks and macros, but it didn't work well either (user code can't make futures compose and optimize as well without compiler's help, especially when you want borrow checker to work with it).
> 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.
Yeah on top of that I've seen virtually no evidence that Rust projects really decay. I bet you can compile some really old Rust projects with the latest Rust with no problems.
In my experience the "oh god I have to compile a 10 year old program" dread hierarchy (from least to most dread) is:
1. Go. Very reliable.
2. Rust. Also very reliable.
3. C++. Sometimes stuff breaks, e.g. when they change the default C/C++ version and dependencies don't specify it. That happened to me recently.
4. Python. They deprecate stuff all the time that is often actually used (e.g. a load of stuff in pkgutil recently).
Yeah, it's pretty weird that they're hating on the six week release cadence because...they think the changelogs are too long? Just don't read them then!
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.
This is the case, when author argues about the right thing (you do not need Rust everywhere on every project and in every feature, especially if your team has 0 prior exposure to Rust or at least C++), but provide very awkward arguments which are not aligned with core thesis.
It's not mentioned, that the language itself is designed in such a way, so it requires a lot of boilerplate involving traits. The same results (both safety and speed) are achievable without using traits at all but by relying on duck-typing.
Every single one of this authors articles that I've read (and it's a fair few), are poorly argued, and generally incorrect. It would be easy to engage and disprove, but it's better not to give this air. Just say no to kerkour.
This is largely FUD, written with the intent of sounding professional and with expertise, but in practice there are many tell-tale signs that the author doesn't really know what they're talking about.
> the biggest drawback of async is the fragmentation of the ecosystem
95% of the ecosystem uses tokio nowadays. async-std has been dead for a long while. There are other runtimes for specialist purposes, but pretty much all async libraries will work with tokio, and you should just use tokio. It's fine. It's well maintained. It's not going anywhere. It's hit a stable 1.0. There is basically no reason to not use it.
> So, if you think that you didn't have enough work solving the problems of your users, you now also need to update your toolchains, Dockerfiles, dependencies and more, every 6 weeks.
This is complete rubbish. Rust's edition system means that Rust code written back in 2015 will (largely, bar some minor soundness issues that have been found since then) still compile. You're under no compulsion to update anything, and cargo's lockfiles ensure that your builds don't suddenly break. If you want to upgrade, do so! But it's exceedingly rare that code ever needs to change when doing so. It's about a painless an upgrade experience as it's possible to have in this industry.
> Rust is betting everything on a powerful language backed by advanced theory, but it forgot that developers need more than a language to build solutions to businesses' problems.
No, it didn't. Rust's standard library is not designed to give you everything you need to build a large program. Instead, it's designed to specify the interfaces that other libraries in the ecosystem require to talk to one-another, and it's been remarkably successful at that. Take a scroll through [the docs](https://doc.rust-lang.org/std/) and you'll see that: it's almost all traits, fundamental types, and other shared abstractions that are used by the rest of the ecosystem. Any non-trivial program is supposed to end up with third-party dependencies: the critical thing is that those dependencies can talk to one-another painlessly, and that promise is largely delivered upon: everybody uses the same interface for `Future`, `Iterator`, `From/`Into`, `Allocator`, `Clone`, `Eq`/`Cmp`/`Hash`/`Ord`, `Error`, `Debug`/`Display`/`FromStr`/`ToString`, `Read`/`Write`, `Sync`/`Send`. That's the sign of a remarkably successful and well-engineered set of abstractions.
I am not sure how many times RIIR helped me, my customers, teams to achieve better outcomes. Energy use matters. Memory safety matters. ML (Meta Language) features are a bliss to C/C++ languages. With the coding agents picking up Rust is much easier than it was 5 years ago. I am not sure what impact the lack of crypto primitives in the standard library even has. I can use hashing (even the more advanced ones like blake3) and some of the NACL primitives and that is fine.
Async Rust is a bit hard, I agree. Function coloring is probably not the best, but I am not sure how to not have that in a compiled language like Rust, or how to improve it.
I've now worked with 3 teams that have moved from Python (2/3) and C++ (1/3) to (async) Rust. All successfully, all with less bugs, moving faster, etc.
28 comments
[ 6.2 ms ] story [ 55.7 ms ] thread1. 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.
But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices
This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.
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?
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.
If your reference is JS or C#, then Rust's async has more friction and annoying details. But Rust is generally harder due to being low-level and picky about memory management and thread-safety details. In a way it's a compliment that Rust's usability even gets compared to GC languages.
If you compare it to hand-rolling state machines in C, or even callbacks in pre-async Rust, then it's an amazing simplification and a very sweet syntax sugar. Especially when you want async code composable, supporting control flow and cancellation.
If you compare it to naive sync Rust while ignoring the extra capabilities that async adds, then async is more complicated and less feature-complete (Streams have more moving parts than Iterators, generic async closures have trickier syntax than generic sync closures, there are scoped threads but no scoped multi-threaded futures, etc). IMHO the difference isn't large and it's reasonable for what you get.
There's also a view that async/await syntax is fundamentally misguided and shouldn't exist at all. From Rust's perspective that's an agree-to-disagree. Rust tried having green threads first (before 1.0) and decided it was too intrusive and magic for a low-level systems language. Rust tried to make do with just threads, callbacks and macros, but it didn't work well either (user code can't make futures compose and optimize as well without compiler's help, especially when you want borrow checker to work with it).
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.
In my experience the "oh god I have to compile a 10 year old program" dread hierarchy (from least to most dread) is:
1. Go. Very reliable.
2. Rust. Also very reliable.
3. C++. Sometimes stuff breaks, e.g. when they change the default C/C++ version and dependencies don't specify it. That happened to me recently.
4. Python. They deprecate stuff all the time that is often actually used (e.g. a load of stuff in pkgutil recently).
5. JavaScript. Good fucking luck.
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.
Example Amazon uses Rust mostly for actual systems programming, writing hypervisors and cloud infrastructure low level services.
They have plenty of other stuff in there as well.
As someone who programs in both go and rust, I could not agree more.
> the biggest drawback of async is the fragmentation of the ecosystem
95% of the ecosystem uses tokio nowadays. async-std has been dead for a long while. There are other runtimes for specialist purposes, but pretty much all async libraries will work with tokio, and you should just use tokio. It's fine. It's well maintained. It's not going anywhere. It's hit a stable 1.0. There is basically no reason to not use it.
> So, if you think that you didn't have enough work solving the problems of your users, you now also need to update your toolchains, Dockerfiles, dependencies and more, every 6 weeks.
This is complete rubbish. Rust's edition system means that Rust code written back in 2015 will (largely, bar some minor soundness issues that have been found since then) still compile. You're under no compulsion to update anything, and cargo's lockfiles ensure that your builds don't suddenly break. If you want to upgrade, do so! But it's exceedingly rare that code ever needs to change when doing so. It's about a painless an upgrade experience as it's possible to have in this industry.
> Rust is betting everything on a powerful language backed by advanced theory, but it forgot that developers need more than a language to build solutions to businesses' problems.
No, it didn't. Rust's standard library is not designed to give you everything you need to build a large program. Instead, it's designed to specify the interfaces that other libraries in the ecosystem require to talk to one-another, and it's been remarkably successful at that. Take a scroll through [the docs](https://doc.rust-lang.org/std/) and you'll see that: it's almost all traits, fundamental types, and other shared abstractions that are used by the rest of the ecosystem. Any non-trivial program is supposed to end up with third-party dependencies: the critical thing is that those dependencies can talk to one-another painlessly, and that promise is largely delivered upon: everybody uses the same interface for `Future`, `Iterator`, `From/`Into`, `Allocator`, `Clone`, `Eq`/`Cmp`/`Hash`/`Ord`, `Error`, `Debug`/`Display`/`FromStr`/`ToString`, `Read`/`Write`, `Sync`/`Send`. That's the sign of a remarkably successful and well-engineered set of abstractions.
Async Rust is a bit hard, I agree. Function coloring is probably not the best, but I am not sure how to not have that in a compiled language like Rust, or how to improve it.
And now we have AI.