4 ms·
> The result monad/option monad and match statements from OCaml/Gleam Do you mean actual monads or just the specific result/option containers? If you mean a fu
by matt_kantor 6mo ago
> The result monad/option monad and match statements from OCaml/Gleam
Do you mean actual monads or just the specific result/option containers? If you mean a fully-fledged monad abstraction then you need a more sophisticated type system than what Kotlin provides (i.e. higher-kinded types).
- tadfisher 6mo agoKotlin itself has opted for inline union types to represent error results: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441-rich-errors-motivation.md https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441... The existing Result type was a mistake to expose to users, IMO, as it encourages exceptions-as-control-flow and error type hierarchies which complicate error-handling even further. The convenient `runCatching` API also completely breaks reasonable error-handling on the JVM and Kotlin's structured concurrency (which happens to use exceptions-as-control-flow to signal coroutine cancellation). Overall, Kotlin is moving away from higher-kinded types in the core language, not toward them.
- matt_kantor 6mo agoI'm not a frequent Kotlin user but none of that surprises me. My comment was asking about nobleach's imaginary "perfect programming language", which is clearly not Kotlin.
- nobleach 6mo agoI'd settle for the Result/Option containers. Kotlin does have ArrowKt to attempt to achieve all the functional goodness of Scala. I think for my needs though, I'd appreciate Rust's "Result".