As a "systems" programmer I feel strongly that Rust is the wrong fit for most applications, but is suffering from web and application programmers needing that next fix of rewriting the world in a new shiny toy.<p>You could have a garbaged collected language with an actor model, implicit yielding, easy runtime inspection, easy to learn, easy to teach, but instead you're picking Rust because it's cool. The author could have just used Elixir, or Go, and they'd spend half of the time they did learning and writing Rust code on the millionth web framework/userspace work stealing scheduler. I mean, they know Erlang, so why not Elixir? Why not Phoenix which they've been working on for like 10 years now. It actually astonishes me how often these very well trodden wheels get reinvented for no reason at all because web frameworks are apparently all developers work on these days.<p>Systems programming absolutely needs Rust, but this "it's a great fit for everything" has to stop. You don't need manual memory management. You don't need to think about lifetimes. You don't need explicit yielding. If you're choosing Rust because you just want to use a complicated language, learn a new toy, feel like your web app needs to go at light speed, maybe stop and consider that you're doing yourself and whoever your building your software for a disservice when something like Go is way easier and will cover the 95%. I have seen these garbage collected languages scale to incredible loads with good engineering that focused on good architecture rather than magic tools.<p>If on the other hand you actually need to write software that's going to run on a TPM, or in the kernel, interface with a new hardware protocol, ok, use Rust. C is obviously a huge danger and we've known that for a very long time. That's what Rust is good at, and trying to use it for everything just leads to code bases that are way more complicated than they ever needed to be. And truly, being as simple as possible is almost always the right way to go.