This is why Haxe is awesome. You can target a sloppy langauge and still get the benefits os a ML-like typesystem.

> At the first glance, this code looks noisier and hard to understand

Because of your inconsistent line-breaks!

Ah, Either. Didn't recognize you from the first glance.

Now we need to invent do-notation, higher kinds and typeclasses and this code would be well composable.

I love how everyone here shares real experience with Kotlin and Result, it’s cool to see different views that actually teach something.

Use the builtin Result class and runCatching/fold and be done with it. Yes, it has shortcomings but works well enough in practice.

How to rewrite boring, easily understood code into abomination. I'm not surprised to see Kotlin, for some reason there's a huge inferiority complex in Kotlin community where you have to write the most convoluted pseudo-fp code possible (not smart enough to use ML or Haskell, but still want to flex on Java noobs).

I can't wait until they release rich errors and this nonsense with reinventing checked exceptions will finally end.

This is really just a syntactical issue. Not one of types or semantics.

Non trivial operations have errors when the happy path fails. And with web apps IO can fail anytime, anywhere for any reasons.

Sometimes you want to handle them locally, sometimes globally. The question is how ergonomic it is to handle this all for a variety of use cases.

We keep reinventing the wheel because we insist that our own use cases are “special” and “unique”, but they really aren’t.

Personally, I think Java’s proposal on catching errors in switches, next to ordinary data is the right step forward.

Monads are great. You can do lots of great things in them, but ergonomic they are not. We should avoid polluting our type systems where possible.