It is not much weaker, but more pragmatic. A typical application has this need to represent a "missing" value quite often and adding a special `?`-based syntax for it totally pays of in practice.
However, it is important to not that `String?` in Kotlin is not a syntactic sugar for `Option<String>`, but a syntactic sugar for `String|null`. The difference between the two might seem minor, but is quite big pragmatically, especially when combined with flow-sensitive typing.
Null is a concept--there is no data here. We need the concept and code needs to be able to act on it. If you rewrite the code to avoid all possible nulls you have done nothing to ensure that everything is operating on sane data, you have simply removed the easy mechanism that flagged cases the developer failed to handle.
In most cases you're better off going boom than operating on wrong data and getting rid of nulls shifts the balance towards the latter.
4 comments
[ 4.5 ms ] story [ 19.7 ms ] threadHowever, it is important to not that `String?` in Kotlin is not a syntactic sugar for `Option<String>`, but a syntactic sugar for `String|null`. The difference between the two might seem minor, but is quite big pragmatically, especially when combined with flow-sensitive typing.
Because
isn't that different than the author's Kotlin example.Null is a concept--there is no data here. We need the concept and code needs to be able to act on it. If you rewrite the code to avoid all possible nulls you have done nothing to ensure that everything is operating on sane data, you have simply removed the easy mechanism that flagged cases the developer failed to handle.
In most cases you're better off going boom than operating on wrong data and getting rid of nulls shifts the balance towards the latter.