Nested nullable types collapse to the same type, meaning it's very easy for generic code to contain really subtle bugs. If you have some generic code that has a T? and assumes that whenever it is null it is not T, this assumption will be almost correct and very easy to miss during testing.
Also, it's very common to have option-style code and as your code evolves you need to refactor it to either/result-style code (that includes a reason why something was not present) - indeed I'd say this almost always happens in code that lives long enough. In kotlin this is unnecessarily difficult because it's impossible to write code that works with both nullable types and an either/result-like type, and since null has special language-level support you can't even use the same syntax.
For me, there are two killer reasons for Kotlin to handle nullability as it does: smooth host platform interoperability and zero overhead. The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries. And with some annotations, Kotlin's nullability support can be applied to those existing libraries. As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT. And both of these concerns apply to all of Kotlin's target platforms.
> The existing huge mass of JVM libraries use null, so by embracing that rather than adding a new wrapper object like Scala's Option (or even JDK 8+'s Optional), Kotlin works smoothly with all those libraries.
Recent JVM libraries have (rightly) moved away from null. Using e.g. JDK8 streams from Kotlin is very cumbersome (noticeably more cumbersome than using them from Scala). The special treatment of interop also creates a bunch of special cases in the language that break your usual assumptions: extracting a common method call won't always work, adding explicit types can change behaviour. It's one of those things that looks like a good idea in the small but creates more problems in the large.
> And with some annotations, Kotlin's nullability support can be applied to those existing libraries.
Again this is a case of Kotlin refusing to learn from history. Look at what happened with the JSR308 checker and adding nullness annotations to existing libraries. Someone adds the annotations and everything seems great, then other people make changes to the library and don't maintain the annotations and they become lies.
> As for zero overhead, an Option or Optional is another object, and the overhead of that object can't be completely optimized away by the JIT.
People who care about zero overhead wouldn't be using Kotlin in the first place. The raison d'etre of the JVM is safer programming with fewer crashes, even if that means a little performance overhead some of the time. (For the record you're wrong: in the cases where the JVM stack-allocates an option or optional the memory pattern is exactly the same as if you'd used a nullable value instead. But that's not the point).
> People who care about zero overhead wouldn't be using Kotlin in the first place.
Depends on the target platform. When developing for Android, one can't entirely escape the JVM (or rather, ART), and developing entirely in a JVM language eliminates JNI overhead. And I'm guessing ART doesn't have all the advanced optimizations of HotSpot.
