Even 8 years later, Dan's insights remain as valid as ever, yet there's precious little progress.

One point that has always annoyed me: Exists x . x + 1 < x. While I can forgive C for this defect given the history, the fact that this is broken in even Haskell is mind boggling. At the very least this should trap, but preferably, like in Scheme, integers should by default be unbounded.

I heard that Swift catches the overflow (and underflow). Rust also does that, but only in debug builds. So now we're finally seeing the mainstream languages adopt the integer-overflow-as-an-exception approach.

Rust had used unbounded integer literals by default for some time, so `let a = 1` was an error unless the type could be inferred otherwise. But it was abandoned as it caused some ergonomic problems. Now the integer literals without a suffix are considered `i32`. Given the overflow is catched in runtime, I believe this is a good compromise between the two extremes.

Certainly trapping overflow is progress, but it's not that hard to implement unbounded integers such that the common case (small integers) are just as efficient as the modulo arithmetic we use today.

Sun's SPARC even included hardware support for this (TADDcc, TSUBcc), but programming languages didn't exploit it and the support was removed.

This will only change once there's enough demand that supporting it in hardware becomes a competitive advantage. There's plenty of precedence for this, eg. various crypto support in x86, the evolution of GPUs, networking accelerators, etc.

I intend to change Reduceron to use unbounded integers by default so that the promise that "Well typed programs don't go wrong" isn't a blatant lie.

Javascript and user-submitted forms are trusted code on modern browsers and web apps. And people wonder why we need to upgrade our browsers every two weeks. (Well, besides feature creep)

There even is a section on enforcing explicit data flow (see 3.1)