Rust Is Not a Memory-Safe Language
The article argues that Rust is not truly memory-safe despite its design goals, pointing out that unsafe blocks, FFI calls, and memory leaks (via Rc/Arc cycles and Box::leak) can still introduce memory vulnerabilities, and that the language's safety guarantees only hold if the programmer follows strict rules.
Background
- The article argues that **Rust's memory safety guarantee is limited to safe (non-unsafe) code** — and that real-world Rust projects routinely rely on `unsafe` blocks (e.g., for FFI with C, low-level hardware access, or performance tricks), which bypass the borrow checker and can introduce the same memory bugs (use-after-free, buffer overflow) found in C/C++.
- **Rust's core pitch**: it prevents memory errors at compile time via its ownership/borrowing system without needing a garbage collector. The article challenges this by pointing out that `unsafe` Rust is widespread in practice and that the ecosystem lacks rigorous auditing of those blocks.
- This is part of a long-running debate in systems programming: is Rust truly safer than C++ in practice, or does its "memory safe" branding overstate the real-world risk reduction? Critics (including some security researchers) argue that memory safety claims should be limited to safe Rust code only, while proponents note that even with `unsafe`, Rust localizes risk better than C++.