No nulls, no nullability bombs.

Forcing devs to pre-fix/avoid bugs before the compiler will allow the app means the programs are more correct as a group.

Wrong, incomplete, insufficient, unhelpful, unimpressive, and dumb are all still very possible. But more correct than likely in looser systems.

▲ fc417fc802 4 days ago | parent [-]

> No nulls, no nullability bombs.

I hate this meme. Null indicates something. If you disallow null that same state gets encoded in some other way. And if you don't properly check for that state you get the exact same class of bug. The desirable type system feature here is the ability to statically verify that such a check has occurred every time a variable is accessed.

Another example is bounds checking. Languages that stash the array length somewhere and verify against it on access eliminate yet another class of bug without introducing any programmer overhead (although there generally is some runtime overhead).

	▲	yencabulator 4 days ago \| parent [-]
		The whole point of "no nullability bombs" is to make it obvious in the type system when the value might be not present, and force that to be handled. Javascript: `let x = foo(); if (x.bar) { ... } // might blow up` Typescript: `let x = foo(); // type of x is Foo \| undefined if (x === undefined) { ...; return; } // I am forced to handle this if (x.bar) { ... } // this is now safe, as Typescript knows x can only be a Foo now` (Of course, languages like Rust do that cleaner, since they don't have to be backwards-compatible with old Javascript. But I'm using Typescript in hopes of a larger audience.)