[K0nserv]

> If you want to make pointers not have a nil state by default, this requires one of two possibilities: requiring the programmer to test every pointer on use, or assume pointers cannot be nil. The former is really annoying, and the latter requires something which I did not want to do (which you will most likely not agree with just because it doesn’t seem like a bad thing from the start): explicit initialization of every value everywhere.

To me this is the crux of the problem with null. It's not that null itself is a problem, it's that nothing communicates when it can be expected. This leads to to anti-patterns like null-checking every single pointer dereference. What's need is a way to signal when and when not `null` is valid under your domain model. This is precisely what stuff like `Option` does. Without a signal like this, programming feels like a minefield, where every dereference is liable to blow up, personally I'm done with that kind of programming.

The latter part of the post about individual-element vs grouped-element mindset is interesting, but I'm not sure it refutes the need for null or reasoning about it.

EDIT: It's also worth noting that Rust can still zero initialise entire structs despite element-wise initialisation when the valid bit pattern for the struct is 0.

[DarkNova6]

I think this is about 2 problems coming together:

- 1: In C (and relatives), you cannot rule out that any pointer is not-null. Simply due to pointer arithmetic.

- 2: Some values have no default-zero state.

On #2 I found the EG discussions on the Java mailing lists to be fascinating. Think of innocuous types such as "date", where a default value only causes problems. You end up with something like "1970:0:0" or "0:0:0" and it acts like a valid date, but its use is likely unintentional and leads to follow-up issues.

And once you have multi-threading involved, even a simple null-flag becomes a difficult technical challenge to implement under all conditions.

[K0nserv]

While null-pointers are possibly under #1 it seems much more likely that you'd produce other kinds of invalid pointers(out of bounds, unaligned etc) than nullptr. The use of null pointers to signal absence and failure is surely the most common source of them in C (and relatives).

I've always understood the billion dollar mistake to be more about #2 and language like Java in particular. Agree about default values being bad, it's one of my primary reservations with Go.

[DarkNova6]

> While null-pointers are possibly under #1 it seems much more likely that you'd produce other kinds of invalid pointers(out of bounds, unaligned etc) than nullptr. The use of null pointers to signal absence and failure is surely the most common source of them in C (and relatives).

Fair point. Still, it just leaves a bitter taste when you want to express something as non-null but can't technically exclude it...