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.

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?

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.

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.

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.

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.

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