> • Pleasant, concise syntax for handling optionality. Not bolted on with an option type.
Optionality is not special enough to be worth a special case in the type system, IMO. Maybe some syntactic sugar could be worthwhile, but not a magic type that behaves differently from other types (which is what Kotlin's ? is) - you need it to behave like a normal type so that you can write and reuse generic code. Arrow-kt can't implement functions that work with nullable values, and has to implement its own Option type instead.
> • Highly efficient translation to machine code. No boxing, no unnecessary branching in the unwrap/!! case.
Getting the semantics right is the important thing; it doesn't matter how fast the code runs if it's broken. It's still possible to compile a well-behaved option type into something unboxed in the cases where it can be represented that way (look at what Rust does, where the option is "packed" if 0 is not a valid value for the inner type, but still does the right thing for Option<Option<T>>, Option<Int> and so on).
With this new feature I'd argue the Java/Kotlin world now has the best handling of optionality of any language, anywhere:
• Pleasant, concise syntax for handling optionality. Not bolted on with an option type.
• Highly efficient translation to machine code. No boxing, no unnecessary branching in the unwrap/!! case.
• Excellent interop with older code written in OOP languages that don't represent nulls in the type system.
• But that older code can be annotated with @NotNull and @Nullable to retrofit the information; within Java IntelliJ will statically analyse these and add warnings where an NPE/panic would occur, when such code is used by Kotlin the annotations cause the types to be correctly derived as nullable or non-null.
• The large wealth of libraries that want to explore object graphs continue to work without being distracted by option/maybe types (e.g. serialisation, UI binding)
• On the rare occasions where you do need to unwrap and you got it wrong, you now get an error message that breaks down the sub-expression where the null pointer occurred, so there's no incentive to break up long chains of dereferences just to get better debugging in case of failure.
That's a featureset around optionality that's hard to match.