You didn't quote the bit above that, "Null Safety is just overhead imho." Having to change all your types for that data is one reason he gives for that assertio

You didn't quote the bit above that, "Null Safety is just overhead imho." Having to change all your types for that data is one reason he gives for that assertion. I don't have a hard stance on that, but I can see where he's coming from. My day job is all Java, and while we do occasionally have to deal with NPEs, they're just NPEs, not segfaults or things that can take down the whole program. They get caught and logged in a thread while the rest of the (server) app marches on. Programmatically, using Optional to signal intention of null as meaningful (and it is sometimes useful to have null as a meaningful "don't know" value, see http://john.freml.in/billion-dollar-mistake http://john.freml.in/billion-dollar-mistake) works well and isn't syntactically laborious. (Additionally Optional chaining with maps is much nicer than the old way of nested if-not-null checks, but sure a "?." operator or similar would be slightly nicer.) Common Lisp complects nil and false and the empty list '(), which originally annoyed me quite a bit, but after working with it more I see it as deeply pragmatic and it simplifies a lot of code while also making many types of annoying errors in other null-supporting languages either not relevant or much more trivial to fix. Additionally its OOP system has a function-call syntax of (method obj arg) instead of something like obj.method(arg) so in error logs you'll see "no applicable method for the generic function #method when called with arguments (nil arg)" (and in development you have the excellent condition system to resolve this without unwinding the stack and losing state, including the choice to define a method that explicitly handles a null object). But I don't see the programming language fashions moving any closer in that direction...