Earlier quoted context omitted.
> this falls for the same kind of over-engineering which caused log4j's issues in the first place Because it uses an effects system, which are designed to control side effects like the one which caused log4j's vulnerability, it looks like a reaction against log4j, not "more of the same problem". Whether this is a sound approach or not, I cannot say. But definitely not a case of log4j-like overengineering.
Sadly the effect system isn't granular to narrow down what effect is happening other than "IO", which could be logging, network, disk access, rm -rf /. And without that visibility it doesn't provide you much advantage. Haskell similarly suffers, I'd like to see IO broken down into composable units of functionality so I can see if e.g. my logging library has some ridiculous network constraint.
But there is something on the horizon for Scala:
https://github.com/lampepfl/dotty/blob/release-3.1.0/docs/do...
One can have a proper effect system on the JVM also already today with Flix:
https://en.wikipedia.org/wiki/Flix_(programming_language)#Po...