The post is a practical argument about how Zig handles assertions. In Zig, `std.debug.assert` does not disappear in release builds by default. Instead it remains a runtime check unless you choose an aggressive release mode that strips safety checks. The author’s point is that assertions are often the last line of defense for invariants that should never be violated, so treating them as debug-only is backwards. If a condition indicates a programmer bug, crashing loudly in production can be the right outcome. The post also notes that compilers can sometimes use an assertion-like condition as an optimization hint, which raises the stakes around what an assert means.
For engineering leaders, this is really about failure policy and language design: if your invariants only exist in test builds, production becomes your least-checked environment, but if you blur runtime checks with optimization hints, you invite brittle code and miscompilations.
Mostly positive on keeping invariant checks alive in production, with the strongest skepticism aimed at any design that lets assertions silently turn into optimization assumptions or disappear by build mode.
01 Runtime assertions and compiler assumptions should be separate language features, not two modes of the same keyword.
The C++ `[[assume]]` work and MSVC’s experience were cited to show why. When teams used an assert-in-debug and assume-in-release pattern, removing the assumptions reportedly improved reliability and even produced a 1 to 2 percent speedup. That flips the usual intuition that assumptions are a free optimization win.
A check that can become an assumption is doing two incompatible jobs. Separate the safety mechanism from the optimizer hint.
02 Debug-only assertions create organizational debt that can last for years.
One commenter described a large C++ codebase that relied almost entirely on QA-build asserts instead of unit tests or production checks. The team planned to enable assertions in production after cleaning up failures, but stayed stuck in “soon” for years. Once a system depends on checks never firing in real deployments, turning them on becomes a migration project, not a flag flip.
If production cannot tolerate your assertions today, that is a signal about code quality and process. Deferring the cleanup compounds the cost.
03 Java ended up teaching a useful lesson by accident.
Its `assert` is syntactically distinct and can avoid evaluation when disabled, but in practice many teams do not rely on it because enabling it consistently in production is awkward and `AssertionError` is often too disruptive. That vacuum gets filled by always-on defensive checks like `requireNonNull()`, which means many real-world Java codebases already distinguish between invariant checks and recoverable runtime validation even if the language does not frame it that way.
Teams naturally split bug-detection asserts from user-facing validation. Languages that blur those paths force developers to recreate the distinction with ad hoc APIs.
04 The more useful framing is not “assert or no assert” but “what contract are you expressing, and what failure mode do you want.
” The Rust crate `assertables` was offered as an example of one API family that supports panic, debug-only panic, or `Result` return. Others pointed to Design by Contract and fuzzing as ways to make invariants systematic instead of ornamental. Assertions are strongest when they are part of a testing and specification strategy, not scattered checks of obvious conditions.
Assertions work best as one layer in a broader contract strategy. Pair them with fuzzing, tests, and explicit error paths instead of treating them as a catch-all.
01 Some of the criticism overstates Zig’s design because the article is talking about `std.
debug.assert`, not a hard language limitation. Zig lets you write your own assert helper that disappears in release builds if that is the behavior you want. The practical complaint is then less “Zig got asserts wrong” and more “the standard default encodes a particular philosophy.”
This is partly a standard-library policy choice, not a language prison. Teams that want C-like debug-only asserts can build them.