RAII and the Rust/Linux Drama

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.”