[matt_kantor]

> 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]

Kotlin itself has opted for inline union types to represent error results: 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]

I'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]

I'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".