I keep running into very vocal Rust supporters who say it’s clearly the best choice for performance, safety, and maintainability, but my real-world experience has been more mixed. I’ve seen good results, but also steep learning curves, slower onboarding, and debates that feel louder than helpful. I need help figuring out when Rust truly is the right tool and when the community hype may be overstating it.
Rust supporters are loud because Rust gives them a clean story. Memory safety without GC. Strong tooling. Good perf when you hit the happy path. That part is true.
The missing part is cost.
You pay in compile times, harder onboarding, and code complexity around lifetimes, traits, async, and error types. Teams with mixed skill levels feel this fast. A senior Rust dev moves fine. A normal backend team often slows down for months. I’ve seen features ship later, bugs drop, then hiring gets harder. Both happened at once.
Perf is also situational. In CPU-bound services, parsers, storage engines, Rust often wins. In CRUD apps backed by Postgres and Redis, language choice matters less than query design, indexes, caching, and I/O. If 80 percent of your latency is network and DB time, rewriting Go or Java into Rust won’t save you. I’ve watched teams burn 6 months for single-digit gains. Thats not a win.
Maintainability depends on who owns the code. Rust makes some bad states impossible. Great. It also makes some simple changes annoyng if the type system gets fancy. You get fewer runtime bugs, but you may get more ‘only Alice understands this crate graph’ risk.
Use Rust where failure costs a lot, perf matters, and the team wants the trade. Infra, embedded, parsers, security-sensitive code, shared libs. Skip the hype for ordinary web apps unless you have a clear bottleneck or staffing plan.
So no, they aren’t always right. They are often loud. Rust is a tool with sharp tradeoffs, not a moral victory.
A lot of Rust discourse is just identity politics for programmers. That’s the blunt version.
I mostly agree with @himmelsjager on tradeoffs, but I think Rust fans also oversell ‘maintainability’ in a weirdly selective way. Preventing whole classes of bugs is maintainability, sure. But so is letting a new hire make a small change without spelunking through trait bounds, macros, async pinning nonsense, and compiler errors that read like a legal brief. People act like fewer segfaults automatically means easier long-term ownership. Not always.
Also, ‘best performance’ gets thrown around way too casually. Rust gives you access to high performance. It does not magically produce it. Plenty of Rust code is mediocre because the algorithm, architecture, or I/O profile dominates everything. If your app is mostly waiting on a database, congrats, your ultra-safe nanosecond-optimized service is still waiting on the same DB.
Where I disagree a bit with the anti-hype crowd is this: Rust’s strictness can pay off earlier than people admit. Not just in kernels and embedded stuff. I’ve seen it help in boring backend systems where correctness mattered and concurrency bugs were a real pain. So it’s not only for niche wizard work.
But ‘clearly the best choice’ is fanboy talk. The right question is: best for what team, what problem, what hiring market, what deadline? Rust is excellent. It is not automatic. And some evangelists are absolutely just loud lol.