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>

user:	achaeus
created:	December 14, 2025
karma:	1