Kotlin calling Java: you have to manually check return values for older libraries and won't notice where you're passing in null because that's a normal, safe thing to do when calling Kotlin. Kotlin calling Kotlin: you use null a lot, you never hit a problem with null. Scala calling Java: you have to manually check return values for older libraries but at least passing in null can't happen. Scala calling Scala: you never use null, you never hit a problem with null. > Kotlin's approach is superior in that it requires developers to deal with nullabilityīut it doesn't force them to deal with nullability when interacting with Java which is the only case where it matters. Why do you want an extra way of representing the same thing with more special cases? It's certainly not worth the cost of working with a weird, second-class type that you can't abstract over like other types).

Nullable types are worse than Option in every way that matters (yes they save a few bytes of memory occasionally, but who the hell cares, if you care about shaving 8 bytes off an object you won't be using the JVM in the first place.

Null safety in kotlin