5 ms·
It's not immediately obvious, but when you write some Kotlin you'll see. Little things that are a apin in Java and elsewhere are quick and natural in Kotlin:
by pabl0rg 9y ago
It's not immediately obvious, but when you write some Kotlin you'll see.
Little things that are a apin in Java and elsewhere are quick and natural in Kotlin:
- nullable types are smoother than Options
- null checks are relatively painless
- the stdlib works with you, not against
- named parameters and optional parameters means no need for builders
- etc. Etc.
- _Codemonkeyism 9y agoI 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?