[ShardPhoenix]

>You also would probably mention that the code would be less likely to be buggy and crash due to the null safety principle. Not really. Although it makes it easier to deal with null values, Kotlin is no miracle cure. A null value comes from somewhere. If your logic is wrong, your logic is wrong, no matter what is the language used.

I haven't used Kotlin extensively enough to know how much the null safety really helps, but this reasoning seems incorrect to me. You could extend it to say that static types aren't useful either, but in both cases there's a significant benefit from getting faster feedback that your logic is (or might be) wrong.

[mathw]

I've found it enormously useful to have languages which check on possible nulls and make sure I've attempted to handle them, rather than just merrily throwing a null reference exception when I get a surprise.

It's also extremely handy to know that a given method simply cannot return null, based on nothing but its type, in a way that the compiler will have enforced.

I feel the author is really underestimating the impact of null safety on avoiding these annoying bugs in the first place. To my mind it's like saying dynamic languages are as solid as static once once you've written your test suite - that test suite's probably going to have tests in it that you're returning the type you expected from a function, something the compiler could easily be handling for you. What a waste of time! Just like unchecked null handling.