You Must Fix Your Asserts (Zig)

A seemingly nerdy post about a coding safety check turned into a full-on "are we being reckless in production?" brawl. Zig developer Loris Cro argued that turning off asserts — little built-in sanity checks that scream when something impossible happens — is not just questionable, but an "irredeemably bad practice." In plain English: if your app hits a condition that should never happen, Cro says it should crash loudly instead of silently wandering off into chaos. And yes, the comments immediately split into tribes.

One camp basically yelled, "finally, someone said it." They argued that in giant codebases, these checks are the only thing standing between a small mistake and a nightmare bug hunt. One commenter pushed fuzzing — automated random testing — like it was the superhero sequel this article forgot to announce. Another dusted off old-school software doctrine, insisting asserts should follow Design by Contract, a formal way of saying, "stop sprinkling them around like confetti."

But the pushback was spicy. Some readers said this is being overdramatic because Zig’s built-in assert is only one kind of assert, and if developers really want checks that vanish in release versions, they can just make their own. Then came the war story: a commenter described a massive C++ company that relied almost entirely on checks in testing, barely any unit tests, and kept promising production safety was coming "soon" — a timeline so cursed it practically became the thread’s punchline. The vibe was part safety lecture, part workplace trauma dump, and part group therapy for programmers haunted by bugs that "should never happen."