August 9, 2026
Assert yourself, internet
Assert(): A Modern How To
Coders Are Fighting Over a Tiny Safety Check and the Comments Got Personal
TLDR: The article argues that assert() checks should be used more broadly to catch bad situations early and make programs safer with almost no performance cost. Commenters were split between “great idea,” “this needs clearer rules,” and the delightfully blunt “just restart the thing if it breaks.”
A post about the humble assert() function — basically a built-in “this should never happen” tripwire in code — somehow turned into a full-on comment section showdown. Author Reza Naghibi argued that these checks deserve a glow-up: use them for correctness, safety, development, and even documentation, and stop treating them like disposable debug stickers. His big pitch? These little checks can make software safer, easier to understand, and barely slow anything down.
But the community did what the community does best: immediately started arguing about the meaning of life, except the life in question was a tiny code statement. One of the strongest reactions came from Ross Bencina, who basically said, “Cool topic, shaky foundation,” complaining that the article starts by raising big questions about what assert even means and then never fully locks that down. Another commenter, rramadass, arrived with pure exhausted-parent energy: “Not this again ...” and insisted assertions should be treated only as checks on program state, not a Swiss Army knife for everything. Meanwhile, iTokio brought chaotic practical energy, saying if a program enters a cursed mystery state, just restart it — ideally with self-healing modules, Erlang-style. And then there was the elegant nerd counterattack: why not bake the checks into the data itself so bad values can’t sneak in at all?
The vibe was classic internet engineering drama: one camp yelling “assert more!”, another yelling “define your terms!”, and a third quietly asking why this isn’t just a normal error message with better manners.
Key Points
- •The article argues that many `assert()` implementations are underpowered and that developers often lack clear guidance on when and how to use assertions.
- •It identifies four primary uses for assertions: correctness, safety, development, and documentation.
- •The article states that assertions can improve static analysis by narrowing the scope for validation and invariant checking.
- •It argues that assertion overhead is usually minimal when assertions are used properly.
- •A sample pattern, `var error = system_call(...); assert(!error);`, is used to illustrate how assertions can expose unhandled edge cases and maintain value correctness.