3 ms·

For the love of all that is good in the world, this is a solved problem, I don't understand why languages like Go, Kotlin, Python etc etc etc continue to insist

by bedobi 3y ago

For the love of all that is good in the world, this is a solved problem, I don't understand why languages like Go, Kotlin, Python etc etc etc continue to insist on not having sane Option, Either, Try etc types.

erik_seaberg 3y ago
Kotlin is deliberately trying to stay closer to Java and more approachable than, say, Scala. It does have sum types and a generic Result, but the builtin special cases for nullability and exceptions are a little more ergonomic (and simplify interop with JVM APIs).
- bedobi 3y ago
  I don't understand this. Kotlin has very deliberately made many choices that don't align with Java, that's the whole point. But more and more people are realizing that Kotlins error handling is a failed experiment and are adopting Arrow instead, as they should. There's nothing demanding about Option, Either, Try etc types, they're literally just objects no different to any other, and they enable you to write functions that actually only return what they say they do, unlike with exceptions. It is exceptions that are difficult and demanding lol. And the Result type isn't very good and not even meant to be used by users of the language.
enriquto 3y ago
> this is a solved problem, I don't understand why languages (...) insist on not having sane Option, Either, Try etc types. This is not a "problem" as much as a conscious philosophical stance: Errors don't actually exist, only conditions that you dislike. All the error handling you need is if/else. Everything else is unnecessary emotional baggage on some conditions that should not pollute your language. And even less so, gasp, your types (!).
unscaled 3y ago
It was only in recent years that Rust has proven that monadic error-handling can be accepted in a mainstream language. At least, I hope it convinced enough people. The more generic approach to error handling, using do monads (in Haskell and Scala) require some sort of do-notation (Scala's "for comprehensions") to be convenient. And I think this is a step that most mainstream languages are still too afraid to take. I would personally be glad for mainstream and some sort of monadic comprehension to become a mainstream language feature the same way closures became, but this is far from the reality. So we are left with special-case solutions for specific problems like error-handling, iteration and nullability. Kotlin made it very easy do deal with nulls without a much ceremony (this is slightly more troublesome in Rust or Scala, for instance), while Rust chose to make error handling easier. Of course, they both repurposed the same operator ("?") for this purpose. What Kotlin does with nullability and what Rust does with error-handling are both becoming quite palatable for mainstream language developers, but it's quite late to change language which have used exceptions (like Kotlin, Java and Python) or error values (like Go) to use monads right now. Entire APIs are built on the existing (and insufficient) error handling scheme. For instance, we're using Arrow's Either on most new projects at work, but still have to deal with a lot of existing Java APIs, which are exception-based.
_ZeD_ 3y ago
Yeah this is a solved problem... with exceptions

by bedobi 3y ago

erik_seaberg 3y ago

Kotlin is deliberately trying to stay closer to Java and more approachable than, say, Scala. It does have sum types and a generic Result, but the builtin special cases for nullability and exceptions are a little more ergonomic (and simplify interop with JVM APIs).

bedobi 3y ago
I don't understand this. Kotlin has very deliberately made many choices that don't align with Java, that's the whole point. But more and more people are realizing that Kotlins error handling is a failed experiment and are adopting Arrow instead, as they should. There's nothing demanding about Option, Either, Try etc types, they're literally just objects no different to any other, and they enable you to write functions that actually only return what they say they do, unlike with exceptions. It is exceptions that are difficult and demanding lol. And the Result type isn't very good and not even meant to be used by users of the language.

enriquto 3y ago

> this is a solved problem, I don't understand why languages (...) insist on not having sane Option, Either, Try etc types. This is not a "problem" as much as a conscious philosophical stance: Errors don't actually exist, only conditions that you dislike. All the error handling you need is if/else. Everything else is unnecessary emotional baggage on some conditions that should not pollute your language. And even less so, gasp, your types (!).

unscaled 3y ago

It was only in recent years that Rust has proven that monadic error-handling can be accepted in a mainstream language. At least, I hope it convinced enough people. The more generic approach to error handling, using do monads (in Haskell and Scala) require some sort of do-notation (Scala's "for comprehensions") to be convenient. And I think this is a step that most mainstream languages are still too afraid to take. I would personally be glad for mainstream and some sort of monadic comprehension to become a mainstream language feature the same way closures became, but this is far from the reality. So we are left with special-case solutions for specific problems like error-handling, iteration and nullability. Kotlin made it very easy do deal with nulls without a much ceremony (this is slightly more troublesome in Rust or Scala, for instance), while Rust chose to make error handling easier. Of course, they both repurposed the same operator ("?") for this purpose. What Kotlin does with nullability and what Rust does with error-handling are both becoming quite palatable for mainstream language developers, but it's quite late to change language which have used exceptions (like Kotlin, Java and Python) or error values (like Go) to use monads right now. Entire APIs are built on the existing (and insufficient) error handling scheme. For instance, we're using Arrow's Either on most new projects at work, but still have to deal with a lot of existing Java APIs, which are exception-based.

_ZeD_ 3y ago

Yeah this is a solved problem... with exceptions