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.
Replies
> 3. You don't need to use async Rust.
Technically correct, but… Want to build a web app, every more or less popular framework is async. Want to make a web request? High change of async. Database? Very likely async, too. A huge fraction of crates are async. Right now crates.io says there are "54172 reverse dependencies of tokio”. And the page that lists them struggles mightily to load. And that’s only direct dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.
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.
> You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust.
Actually if your team doesn't know any suitable languages it could make sense to pick Rust because they will cause far fewer accidental fires in Rust.
(Safe) Rust is much more forgiving of "I didn't know that's how computers work" than a language like C or C++ yet it's as close to the metal as they are which may matter for your application.
If you're hiring programmers they probably already know some suitable languages which should strongly influence your choice, but if the team's main expertise is not programming they may take to Rust much easier than you'd expect.