Okay, I like Rust, really... But, I totally agree it's not just about memory safety.
Rust gives you: Memory safety (mostly), No use-after-free, double-free, buffer overruns in safe Rust.
It does not give you: logic/protocol/cryptographic correctness, supply-chain integrity, side-channel resistance, malicious dependency immunity, auditability, reduced attack surface, or reduced complexity.
In other words, Rust solves one class of bugs extremely well. It solves none of the hard ones.
I get it, memory corruption bugs are Loud, measurable, easy to point at, and easy to sell to management.
That's why they dominate the narrative.
My biggest issue/concern is the dependency explosion problem.
Classic C Example:
- ~N lines of code
- A small number of carefully curated libraries
- Mostly static linking
- Painful to write
- Painful to maintain
- Possible to audit
Rust rewrite:
- Core project +
- 50 direct dependencies +
- 300 transitive deps +
- 900 crates total +
- Thousands of maintainers you have never met +
- GitHub accounts that may disappear tomorrow +
- Build scripts executing arbitrary code at compile time
Security claim: "Memory safe!"
Reality: Attack surface inflation by 1–2 orders of magnitude
You've traded:
"I might screw up a pointer"
for:
"I trust a thousand strangers, their CI pipelines, their update hygiene, their threat models, and their long-term incentives."
...
Rust’s memory-safety guarantees are genuinely valuable, especially for new development. Where I become skeptical is when a rewrite significantly expands the dependency graph. At that point, the security model shifts from "local reasoning enforced by the compiler" to "transitive trust in a very large supply chain". That trade-off isn't always acknowledged, and in some contexts, especially high-assurance systems, it deserves more scrutiny.