RAII and the Rust/Linux Drama

Original Article ↗ Hacker News Discussion ↗

Automatic resource cleanup (RAII) in systems programming is at the center of a debate over Rust’s role in the Linux kernel, with critics warning about potential performance issues from large synchronous destructor runs and arguing for arena-style allocation instead. Many respondents counter that RAII and arenas are compatible, that Rust’s lifetime system enables safe and efficient abstractions for both patterns, and that fears about hidden “magic” cleanup are overstated compared to the real-world error rates of manual C code. The exchange also highlights social and political fault lines: some see anti-Rust and anti-RAII arguments as FUD or resistance to change, while others stress maintainability, tooling, and governance as Rust support continues to expand in mainline Linux.

Overall view of the article

  • Many see the article as shallow: it links other “RAII is bad” pieces, asserts downsides, but presents little concrete data or examples.
  • Several readers say it never clearly establishes that RAII is harmful in kernel code, nor compares real alternatives with evidence.
  • Others find it biased or propagandistic, especially given the author’s formal role representing another language.

RAII vs arenas and performance

  • Multiple commenters stress that RAII and arena/batch allocation are orthogonal:
    • You can use RAII on arenas themselves, or mix arena-backed and individually owned data.
    • Rust supports arenas via crates and the allocator trait; lifetimes can express safe APIs for them.
  • Critics of RAII argue:
    • Large synchronous destructor chains can cause latency spikes, especially if many small objects are torn down at once.
    • RAII makes cleanup “too easy to forget about,” encouraging designs with huge object graphs instead of a few arenas.
  • Counterarguments:
    • The same “big cleanup” stall exists with explicit free/reset calls.
    • Profiling should determine when arenas or custom strategies are needed; RAII is a good default that can be optimized away where necessary.
    • Destructors in typical Rust/C++ patterns are cheap; problems tend to come from poor allocation strategies, not RAII itself.

Rust, C, and the Linux kernel

  • Some insist that C plus “proper tooling” can prevent memory bugs; others counter with the persistent volume of memory-related CVEs and note that static analysis has practical scaling limits.
  • Rust is framed as moving many of those analyses into the type system and compiler, giving stronger guarantees by default.
  • There’s debate over whether Rust is being “forced” into the kernel versus adopted via normal upstream processes; others point out that leadership has explicitly approved Rust and that a dedicated Rust-for-Linux tree existed first.
  • Maintainability concerns surface: one maintainer stepping away is attributed by some to social friction, not technical failure.

Social and psychological dynamics

  • Several comments link resistance to Rust/RAII to fear of change, loss of expertise status, or cultural clash, rather than purely technical objections.
  • Others emphasize that taste and ergonomics matter: some dislike Rust’s annotations and syntax, prefer explicit defer/manual cleanup, or find RAII “too implicit.”