The comparison is even more apparent if you're used to Swift, which has a separate Optional type but the same syntactic sugar as Kotlin for manipulating it.

MaybeNull?.method() ?: default maybeNull.map_or(|v| v.method(), default)

MaybeNull?.method() maybeNull.map(|v| v.method()) MaybeNull ?: default maybeNull.unwrap_or(default) Using Kotlin & Rust syntax, I make the following mental equivalencies: Kotlin's nullable types and Option are exactly the same thing, except with some implicit conversions and smart casts available (marked by the IDE). Swift, Rust, and Haskell all do this I don't know Scala that well, but I'd imagine it would too unless there's some edge case in ScalaJava interop. The compiler compiles Some to a pointer to T, and it compiles None to null. In a sane implementation of Option, there's no space premium for using it over T. I think there's some misunderstanding about what goes on with an Option type in the compiler. 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.

Kotlin null safety