
Kotlin in enterprise - PleaseHelpMe
https://medium.com/@remy.chantenay/kotlin-in-enterprise-71adbdb3cf8f
======
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.

