To clarify:
Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs.
Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.
Option/Maybe solves the problem of things either being there or not (from databases, domain modelling, ...). As a side effect this solves NPEs.
Non-Nullable Types is there to solve (accessing non initialized variables) NPEs.
The Kotlin type system does help though/is essential to correctly implement Option types where other languages like C# can not.
The essential part is you can/should define an Option type with a non-null upper bound. Otherwise you would have a Some() that still might contain a null value. So the side affect of solving NPEs you speak of is only there if a language actually supports non-null upper bounds.
If you allow null as a return type you need to check for null if you want to use it or not. If you return Option[_] people e.g. just use map() on the return value and then map().map().map().map() on that etc. With Option your code usually does not care to check until the very last moment. Sorry my English is not good enough to make the point :-( And I know, saying "You need to use Option (and Applictives etc.) some years to grok" sounds arrogant and unsatisfactory. But I would not go back to a language without Option (and Applicatives etc.) usage in it's culture.