Memory safety absolutists
Memory safety in systems programming is at the center of a heated debate between advocates of Rust’s compile-time guarantees and proponents of Fil-C and similar runtime-checked approaches for legacy C/C++ code. Commenters weigh trade-offs between stricter safety models, performance overhead, ecosystem breakage, and developer ergonomics, noting that Rust is “mostly safe” but still relies on `unsafe` and FFI, while Fil-C can harden existing codebases at the cost of speed. Many argue that language choice should be guided by practical security and reliability goals rather than tribal “language wars,” and that tools like formal verification and model checking may matter as much as the language itself.
Memory safety as goal and its limits
- Many argue memory safety should be a default expectation, especially for widely used software and anything handling untrusted input (codecs, TLS, browsers, OSes).
- Others note real-world incidents are often driven more by social engineering, supply-chain attacks, logic bugs, and config issues than memory corruption.
- Several comments stress: memory safety is necessary but far from sufficient; other bug classes (e.g., Log4Shell-style logic/design flaws) remain.
Rust, Fil-C/Zig, GC languages
- Rust is praised for combining high performance, strong type system, ownership model, and good tooling; many say its value goes well beyond “C++ but safe.”
- Fil-C is seen as attractive for retrofitting safety onto existing C/C++ with strong runtime checks, at the cost of performance and crashes instead of compile-time rejections.
- Some argue Fil-C can be strictly “safer” (no escape hatches), while Rust and GC languages have
unsafe/FFI edges; others counter that this is a theoretical distinction if unsafe is rare and well-contained. - Zig and C are favored by some for pointer-level expressiveness and low-level control, despite acknowledged risks.
Compile-time vs runtime safety
- Rust’s compile-time guarantees are valued for reliability and less debugging; runtime-only schemes are viewed as turning UB into crashes, which is better but still painful.
- Others prioritize “caught anywhere” over “caught at compile time,” and accept runtime checks, fat pointers, or Fil-C–style mechanisms.
Legacy C/C++ and alternatives
- Large legacy ecosystems (kernels, toolchains, GUI stacks, GPU APIs) make “rewrite everything in Rust/GC” unrealistic, motivating Fil-C and similar approaches.
- Some lament C/C++’s historic refusal to standardize safer constructs (e.g., slices/spans with bounds checks) despite decades of memory-safe language experience.
Security tools, OS/hardware, and formal methods
- Model checking, static analysis, and formal verification (CBMC, Kani, WUFFS, verified compilers/OSes) are presented as complementary or superior to language-only solutions.
- Hardware issues like rowhammer and bit flips (mitigated but not eliminated by ECC) show “memory safe language” ≠ “physically safe memory.”
Language wars and culture
- Many are frustrated by Rust vs Fil-C/Zig tribalism and ideological framing (“woke vs anti-woke,” holier‑than‑thou evangelism).
- Several call for pragmatic, domain-specific tradeoff discussions instead of absolutist “one true language” positions.