I have written some Kotlin, and perhaps it's me, but I don't see. "nullable types are smoother than Options - null checks are relatively painless" Might be th

I have written some Kotlin, and perhaps it's me, but I don't see. "nullable types are smoother than Options - null checks are relatively painless" Might be the case, but Options are more expressive in that I can combine them and restrict them with other type classes to express larger constraints. Reusabilty is higher e.g. with Monad transformers like OptionT. So nullable types are less code, but also less expressive as building blocks of larger constructs. They might be also less expressive because they conflate two concepts: Not initialized and not-there, whereas Option expresses not-there and _ (in Scala) expresses not-initialized. "named parameters and optional parameters" Not sure how this more expressive?