February 21, 2026
Compile-time smackdown
Parse, Don't Validate and Type-Driven Design in Rust
Rust tries to catch bugs before they run, but the comments go to war over math, maps, and C++
TLDR: A Rust post argues for baking rules into types so bugs like divide-by-zero can’t slip into running code. The comments explode into a safety vs. simplicity showdown: some praise strict types, others prefer flexible data, with side quests into C++, Clojure, and whether infinity-on-division is a feature.
A Rust blogger says: stop “validating” after the fact and start parsing your data into safer types up front — think a special number that can never be zero, so your divide-by-zero crash can’t even compile. The crowd? Instantly split. HN’s dang rolled in with receipts, linking the classic Parse, Don’t Validate (2019), and the floodgates opened.
One camp cheered the safety-first vibe. Another roasted the “type novel” approach, joking that Rust fans want to move all mistakes to compile-time, including your life choices. A math twist blew up the thread: a commenter coolly declared that dividing a float by zero is actually fine — it returns infinity — which sparked a mini culture war between the math cops and the infinity enjoyers. Meanwhile, the academics showed up with “dependent types” (code that proves things about itself), flexing about checks done “at compile time.” C++ made a cameo too, with a nod to Stroustrup’s concepts paper (link), while the pragmatic crowd threw a Clojure party: fewer types, more simple data, please.
The meme energy? “Types all the way down,” “compile-time police,” and “Infinity is a feature.” The real takeaway: Rust wants ironclad promises; the community can’t decide if that’s genius… or overkill.
Key Points
- •The article advocates encoding invariants in Rust types (“parse, don’t validate”) rather than relying on runtime validation.
- •Division by zero illustrates pitfalls: integer division panics, while float division may return infinity without error.
- •Runtime assertions (e.g., assert_ne!) catch errors at execution but do not provide compile-time guarantees.
- •A newtype (NonZeroF32) with a private field and fallible constructor enforces nonzero denominators at construction time.
- •Shifting invariants into parameters avoids weakening return types to Option/Result, aligning API promises with enforced constraints.