Eliminating Memory Safety Vulnerabilities at the Source

Original Article ↗ Hacker News Discussion ↗

Impact of using memory‑safe languages for new code

  • Central takeaway: you don’t need to “rewrite the world.” Shifting new development to memory‑safe languages (MSLs) can substantially cut memory safety bugs, even while legacy C/C++ remains.
  • Android data discussed: ~60% drop in memory‑safety issues from 2019–2023 without a mass rewrite, mainly by adding new Rust/Kotlin/Java code. Some ask why there’s a plateau and small rise in later years; the blog’s extrapolation for 2024 is seen as a bit “presentation‑driven.”
  • Several commenters note this is encouraging for large legacy C++ codebases that can’t realistically be rewritten.

Rust, interoperability, and language ecosystem

  • Rust is highlighted as the primary low‑level MSL replacement for Android’s C/C++.
  • Debate over Rust’s C++ interoperability: some argue it was “hostile” or slow to support rich C++ interop; others respond that full C++ ABI integration is technically hard and requires compiler‑frontend‑level support.
  • Tools like bindgen, cxx, and emerging interop efforts (e.g., crubit/crabi) are mentioned as pragmatic glue, contrasted with Swift’s tighter C/C++ integration.
  • Concern from shops with millions of lines of C++ that lack of smooth interop is a major barrier to adopting Rust incrementally.

Language trade‑offs: GC, performance, and safety

  • Commenters distinguish “memory safety” from “no GC”: Rust and Swift (ARC) are given as examples of high‑performance, non‑GC or hybrid approaches.
  • Others argue many domains are fine with GC languages (Java, Kotlin, C#, Go, Python, etc.) where engineer time and time‑to‑market dominate.
  • Go is seen as less suited for Android system components (runtime + GC, missing tagged unions), but used elsewhere at Google.
  • Some choose Rust over Go or other MSLs due to enums/sum types, stronger concurrency guarantees, or tighter control over allocation.

Vulnerability half‑life and old code

  • The article’s claim that vulnerabilities “decay exponentially” (most in new/changed code) resonates with people who see older code as “work‑hardened.”
  • Skeptics worry older code may simply be less scrutinized or sits in long‑tail, rarely exercised paths where serious bugs can linger.
  • Nuance: research cited looks at time to discover vulnerabilities; other data on time to patch and on unpatched vulns shows a long tail.

Security process vs language choice

  • One line of argument: memory‑unsafe languages plus weak processes guarantee ongoing defects; languages are “tools that make it too easy to fail.”
  • Another line: focusing only on memory safety ignores equally large or larger classes of bugs (e.g., injection), and the real root cause is lack of robust, enforced quality processes.
  • Many responses treat this as “both/and”: safe‑by‑default languages significantly reduce one high‑impact class of bugs and free up human effort to tackle harder, higher‑level security issues.