Nonsense. It's not all that hard to find well-received stuff on HN critical of Rust (e.g., from a quick search there's [0, 1, 2] and plenty more, especially around async and/or deps). The key is to write substantive/thoughtful/constructive criticism. In fact, that applies in general - substantive/thoughtful/constructive articles/comments are much more likely to be well-received no matter their topic.
This article does touch on some of Rust's weaknesses/pain points, but does an absolutely atrocious job of doing so. Right off the bat you have this:
Example comparison (small benchmark):
# C++ (g++)
$ time g++ main.cpp -o main
real 0m0.4s
# Rust (cargo build --release)
$ time cargo build --release
real 0m9.7s
Yes, Rust's compile times can be long, but if you wanted to demonstrate that then this is pretty much the worst possible way to do so as not only is it not comparing apples to apples (it's comparing a debug build to a release build) but we don't even know what is being compiled!And it's pretty much downhill from there. Like this:
> Suddenly, the compiler starts screaming:
error[E0515]: cannot return value referencing local variable
Well yes, that's an error. It's also wrong in C++. In fact, C++26 makes (some forms?) a hard error as well, so C++ is moving to match Rust in this respect.The code organization example is yet again not an apples-to-apples comparison. It's also straight up wrong to boot.
The migration decision tree is inconsistent as well. If "memory safety is your #1 priority", then C++ with sanitizers is definitely not a viable option.
So on and so forth. If you want to write Rust criticism and be received well, this is definitely not the way to do so.
[0]: https://news.ycombinator.com/item?id=40172033