Here are the four most prevalent themes from the Hacker News discussion, supported by direct quotes.
1. Unreachable Code Paths Should Trigger Crashes
Many commenters argued that when an impossible state is reached, the safest action is to crash immediately. Continuing to execute code in an invalid state is seen as dangerous, as it can lead to silent data corruption or security vulnerabilities.
"At some level, the simplest thing to do is to give up and crash if things are no longer sane." — LegionMammal978
"Better to lose the last few hours of the user's work than corrupt their save permanently." — lmm
2. Assertion Failure Should Not Be Ignored
Participants generally favored using assertions (such as assert(false) or Rust's unreachable!()) over comments to document "unreachable" code. They argued that assertions provide defined behavior and documentation, whereas comments are easily outdated and ignored.
"It really depends on the language you use. Personally I like the way rust does this: ... unreachable!() (panics)." — josephg
"But at least telling people that the programmer believed this could never happen short-circuits their investigation considerably." — tialaramex
3. Type Systems Should Make Invalid States Unrepresentable
There was a strong consensus that modern type systems are the best tool for eliminating the need for these assumptions in the first place. Instead of writing defensive checks or comments, users argued for defining data structures that make it impossible for invalid data to exist at compile time.
"Ideally, if you can convince yourself something cannot happen, you can also convince the compiler, and get rid of the branch entirely by expressing the predicate as part of the type." — thatoneengineer
"Programmers in C-family languages waste most of their time working around the absence of sum types, they just don't realise that that's what they're doing." — lmm
4. The "Functional Core, Imperative Shell" Architecture
Several users suggested structuring applications to separate pure business logic from side effects (I/O). By pushing impure operations to the "shell" and keeping the "core" pure and deterministic, they argued code becomes easier to reason about, test, and maintain.
"A common pattern would be to separate pure business logic from data fetching/writing. So instead of intertwining database calls with computation, you split into three separate phases: fetch, compute, store." — supermdguy
"You wouldn't do it to make it easier to test; you would do it to make it easier to reason about." — grayhatter