"No way to prevent this" say users of only language where this regularly happens
A satirical blog post riffing on The Onion’s recurring “no way to prevent this” gun-violence headline is used to highlight how often memory safety vulnerabilities arise in C and C-based ecosystems, and how normalized they’ve become. Commenters debate whether new projects should still be written in C given the availability of safer languages like Rust, Go, and others, weighing performance, simplicity, tooling, and ecosystem maturity. Many argue that relying on “skilled” programmers and code review is no longer enough at scale, and that both language design and organisational priorities need to shift toward built‑in safety rather than blaming individual developers.
Satire, framing, and Onion reference
- Many note the post is a direct riff on The Onion’s recurring “No way to prevent this” school-shooting headline, extended to C and buffer overflows.
- Some argue the headline cherry-picks a quote; others say the oversimplification is the point of the joke: highlighting repetition and denial.
C, memory safety, and “skill issue”
- Broad agreement that C has powerful “footguns” and that memory unsafety is systemic, not just a “less skilled programmer” problem.
- Disagreement on whether C’s lack of safety is “the language” vs “implementations”; some point to decades of failed attempts at a drop‑in safe C mode.
- A minority argue safe C is possible with strict discipline, but others counter that large real-world codebases consistently accumulate memory bugs.
Alternatives to C and when C is still justified
- Many say new userspace projects should avoid C when possible; Rust, Go, Java, Nim, Zig, etc., can reach comparable performance without common memory bugs.
- Others insist C is still needed for “portable assembly,” legacy kernels, specific embedded targets (e.g., 8051), or vendor SDKs where no practical alternative exists.
- Some object to proposals that distros should politically discourage packaging new C projects, arguing usefulness should trump language choice.
Rust: power, safety, and pain
- Pro‑Rust points: strong memory safety, enums/sum types, safer defaults, good for kernels, TLS, systems code; “unsafe” is explicit rather than the default.
- Critiques: complexity, steep learning curve with the borrow checker, coarse-grained borrowing, slow compile times, poorer fast-iteration ergonomics.
- Some view Rust as too opinionated or “a hammer where every nail is memory safety”; others say safety should be “table stakes” on modern hardware.
Psychology and culture
- Multiple comments compare C (and guns) to identity objects: some programmers emotionally defend dangerous tools and downplay systemic risk.
- Observations of “language xenophobia,” sunk cost, and zealotry in many communities (Rust, C++, JS, etc.); accusations of Rust “cult” vs. counterclaims that every ecosystem has zealots.
- Several stress that management, incentives, and code quality culture matter as much as language choice.
Miscellaneous tangents
- Side discussions on GC vs manual memory, performance myths, sum types, JS’s
this, and a long subthread about furry/anime imagery and professionalism.