Maybe the solution is to ban null pointers, but give every type its own default value. That sounds weird, but hear me out. There are two kinds of types: 1) Ex

Maybe the solution is to ban null pointers, but give every type its own default value. That sounds weird, but hear me out. There are two kinds of types: 1) Exposed data like numbers, strings, structs or containers. These will often go on the disk or wire. Best practice says such types shouldn't have any required parts, otherwise updating the code in production becomes hell. For example, see how Protocol Buffers V3 bans "required" fields and uses default values everywhere. 2) Opaque objects with behavior. Best practice says such objects should be mockable, which makes them de facto nullable, because you can write a mock that behaves like null (throwing an exception on every method, or even looping forever). This is the same as the old distinction between types with deep equality and types with pointer equality (or no equality operation), or the distinction between serializable and non-serializable types, etc. So the idea is that we shouldn't have null pointers per se, but we should allow programmers to construct a default value for any type, which could be spelled like {} or null. Its implementation should vary depending on type. For data-like types the default value should be something like 0, "" or [], and for behavior-like types it should throw an exception on every method. That would work in both static and dynamic languages and cover all uses of null that I've seen, in both production and test code, without losing any convenience or semantic niceness.