Everything Should Be Typed: Scalar Types Are Not Enough
A small mistake, big payout problem
It has been reported that a developer working on a real codebase ran into a nasty bug from a tiny argument mix-up that also touched rust-clippy, and even lamented it on X. The mistake was banal: a function that looks “typed” because it accepts strings and integers still accepted the wrong values in the wrong spots. The result? Wrong sellers paid the wrong amounts. Ouch. Tests allegedly passed; the app ran; nobody noticed until real money changed hands. That sting — disbelief, then anger — is the emotional core here. Who wouldn’t want to scream?
Scalars lie by omission
The write-up walks through the classic positional-parameter trap: seven parameters, three IDs (all strings), four money amounts (all integers). Swap a couple of arguments and the compiler shrugs. The point is blunt: a String is a String is a String, and an i64 is an i64 is an i64. The type checker validates shape, not semantics. Moving to a struct or object — named fields, as many teams do — fixes positional swaps at call sites but doesn’t stop someone from stuffing the wrong ID into the wrong named field. The compiler still only sees base types, not domain meaning.
Types that mean something
The article’s thrust is simple and persuasive: don’t stop at scalar types. The author argues for making domain meaning explicit in types — newtypes, branded/nominal types, or otherwise encoding “shop ID” vs “customer ID” and “gross” vs “net” into the type system — so the compiler can catch category errors, not just shape errors. It’s not just pedantry; it’s insurance. Call it pragmatic paranoia: protect the money, and the trust, before someone files a support ticket.
A nudge for language and team choices
This isn’t a sermon for only statically typed zealots. It’s a reminder for every codebase — JS, Go, Rust — that the illusion of safety is dangerous. The author asks, provocatively: why let the compiler off the hook when a little domain modeling would have saved a lot of pain? If you’ve been burned by a silent semantic bug, that question lands like a punch. The fix is known, cheap in many ecosystems, and worth doing before the next payout goes to the wrong person.
Comments