"The null reference was my billion dollar mistake responsible for innumerable errors, vulnerabilities and system crashes" (paraphrasing). I don't know. This design choice exposed the developer to system realities, and modern language approaches are based on decades of attempts to improve on it, and they are not necessarily better. Safer yes, but more weighty.
Can anyone suggest a better approach for a situation like this in the future? What's better than exposing addressing the problem with a light solution?
"The problem isn't the concept of 'null', but rather that everything can be null, which makes it impossible to distinguish between the cases where null is an appropriate and expected value, from the cases where null is a defect."
https://blog.ploeh.dk/2015/04/13/less-is-more-language-featu...
Which system reality? Plenty of architectures don't have a concept of a null pointer at the hardware level. Other architectures provide multiple address spaces, or segmented memory addressing. Even when a null pointer exists at the hardware level, it doesn't have to be the zero address.
Null pointers are a software abstraction, and nowadays we have better abstractions.
Some kind of an optional/variant type, enforced by the type system.
Or if even that feels too verbose, just a 'nullable' modifier on the variable or field definition, with the default being not nullable.
(Although Optional/Maybe types are definitely my preference based on the languages I've used)