|
|
|
|
|
by AlterEgo7
244 days ago
|
|
This sounds like a "I could not get my head around ZIO/Fuctional Effects ergo it's a needlessly complex overengineered monstrosity" argument. In fact, functional effects provide another elegant solution to problems requiring structured concurrency. You might like it, you might not. But there are many engineers in the Scala community who were bitten by the exact issues of actor deadlocking / difficulty of debugging compared to functional effects that refactored enterprise codebases from Akka (Scala actors) to functional effects. "A simple system that has been battle tested over decades of actual hardcore industrial use". The JVM certainly is not far from that. |
|
There's nothing elegant about ZIO.
> But there are many engineers in the Scala community who were bitten by the exact issues of actor deadlocking / difficulty of debugging compared to functional effects
Because you can't truly retrofit a proper actor model onto a runtime that doesn't support it, and doesn't have proper tools for them.
So they reach for third-party libs that try to implement half of Erlang, often poorly, and get understandably bitten by issues.
> "A simple system that has been battle tested over decades of actual hardcore industrial use". The JVM certainly is not far from that.
The JVM isn't built around built-in support for concurrency and distributed computing.
Erlang's BEAM is. And its built-in primitives and standard library has been around for over three decades.