alt Hacker NewsLots 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.
For the use cases the author is alluding to, you do need to use async. Non-cooperative threaded multitasking isn't a real choice for backends, and Rust doesn't have virtual threads.
Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code, cause they didn't want to be doing blocking stuff with a thread pool. That was a big motivator for Go and Kotlin coroutines, and why Rust and Python put so much effort into adding event loops after the fact.