| Okay, I like Rust, really... But, I totally agree it's not just about memory safety. <rant>
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. </rant> |