> I would prefer to have HKTs and typeclasses, so I may implement my own IO monad.

I'm not a Java developer, and I haven't even read about higher kinded types or typeclasses (the theory side of programming is my weakness); but you picked my curiosity with this.

Can you elaborate how concurrency done this way would look in Java?

Ideally like this: https://zio.dev/reference/#concurrency

Or this: https://hoogle.haskell.org/?hoogle=fork

Some discussion on zio in loom-dev mailing list recently: https://mail.openjdk.org/pipermail/loom-dev/2023-March/00535...

Loom is useful as an underlying mechanism for an IO monad. What I mean is that Java as language still lacks important features so they have to deliver half-baked things like that "structured concurrency". From my point of view these new abstractions are evil - the better ones were out there for a while.

Other than STM, what is special? Almost everything there has an equivalent in traditional imperative programming.

More contracts enforced by the typer.

> Almost everything there

Everything. But the mere presence of "equivalents" doesn't make pure functional programming less valuable.

I have used cats-effect but not ZIO.

My view has been that reinventing imperative programming (IO monad) on math (pure FP) on imperative programming (the machine) brings me no benefit.

What does a coarse-grained effect type get you? The hard part of concurrent programming is concurrency, rather than knowing what code is effectful.

> What does a coarse-grained effect type get you?

For monofunctors: reliable error handling, an ability to re-interpret the same IO structure multiple times, better reasoning during refactorings due to referential transparency.

For bifunctors: the above plus explicit domain (expected) error encoding and even more reliable error handling.