| Yeah, it's just that-if you look at every language ever designed-if the language ships with a built-in construct developers will use and abuse it on every occasion, and every other approach lingers in obscurity. > Which is expected since these two constructs are not aimed at handling errors: they manage missing values. Which is a very small part of handling errors in general. As Kotlin offers special syntax for only this case, developers tend to shoehorn many errors into the "missing-value" design to get the "nice" syntax even if a different approach would have been more appropriate. > Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...). That's not true in practice: Just have a look at funktionale: Despite providing almost the same as Scala's error handling types (partially due to the blatant copyright violations) almost nobody uses it. This is a direct result from having a "first-class" construct in the language: It turns library-based designs into second-class citizens. That's the thing Scala got right, and many of the copy-cat languages got wrong. |
Missing values are not errors.
If you look up a key on a map and that key is not present, it's not an error.
> partially due to the blatant copyright violations
Uh copyright what? On an API?!?