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.
> In fact, functional effects provide another elegant solution to problems requiring structured concurrency.
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.
This seems to be an antiquated view on Scala and the people working on it and it's tooling. Referring to :\ as foldLeft suggests the parent hasn't seen Scala code since 2018 and scalaz which is nowhere to be found nowadays. I've been working professionally with Scala since 2019 and have never come across the symbol soup that was scalaz.
Programming language choice is a matter of taste to a large degree so it's possible the different people value different traits of languages.
"When in doubt leave it out", is a design decision that can be taken to extremes in some cases and many of us feel crippled and don't enjoy such languages. There can be languages that provide powerful abstractions and rely on its users' trust to use them appropriately. Of coyrde, like every tool it can be misused but that should not be the baseline we use for comparison. Because surely we can find dreadful code in every language.
As a closing paragraph I'll just say that Scala 3 is very nicely designed language that simplifies a lot of the sticky point with Scala 2 and allows for a nice blend of OOP and functional programming. Functional programming in Scala is opt-in and progressive and is a good choice for greenfield projects on the JVM. Also a final note, tooling for Scala and Scala 3 specifically has improved a lot to the point where it just works without arcane invitations of the past. Overly confident opinions to the contrary for people who haven't touched the language since 2018, scala 2.11 and sbt 0.13 are quite out of touch.
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.