The Great Concurrency Smackdown: ZIO versus JDK by John A. De Goes

[Ron Pressler]

Hi Alex.

On 12 Mar 2023, at 21:52, Alex Otenko <oleksandr.otenko at gmail.com<mailto:oleksandr.otenko at gmail.com>> wrote:

The whole pitch is about functional effects, not the ability to spin up a lot of threads. It is about the ability to express various effects and combine them. Java lags way behind on this.


Even FP acknowledges that the opposite is the case. Obviously imperative languages compose effects better than pure-functional code because all imperative code “lives inside” a “continuation monad”. What Java does not currently offer (at least not generally) is *typed* effects, but that’s only needed to *restrict* certain effects. While interesting in theory, the practical utility of doing so has not been sufficiently demonstrated to the point where that merits inclusion in Java, a mainstream language. If a high utility of that capability is ever demonstrated, and in a way that comes at a low enough price, it would be at least as easy to support in an imperative language as it is an a pure functional one. BTW, Scala cannot restrict effects either.

Ultimately, the choice between the functional style and the imperative style boils down to an aesthetic preference. Some always prefer one over the other (although the numbers are not evenly distributed) while others, like myself, prefer the imperative style in some situations and the functional style in others. With the addition of algebraic data types, Java is now truly a multi-paradigm language (see https://www.infoq.com/articles/data-oriented-programming-java/) and it nicely supports the functional style where we think the largest number of people may enjoy it most: data processing and transformation.

When it comes to concurrency, the choice to offer imperative primitive building blocks *first* is an easy one: For one, that is the style that most closely aligns with the low-level workings of the platform. There is one and only one concurrency unity that is reified in the platform and that the platform can observe — the thread. So imperative building blocks are more primitive on the Java platform. For another, that is where most of the ecosystem is, and we want to address the needs of the majority first. We shouldn't force a truly humongous ecosystem into a programming style based on an aesthetic preference of a minority, especially when it doesn’t enable any new capabilities.

Having said that, we are interested in providing a future structured concurrency construct that is more functional, either based on Stream directly or something similar to it and interoperable with it, and work on that is ongoing. JEP 428 states that StructuredTaskScope may not be the *only* structured concurrency construct offered by the JDK. We may even expose another structured concurrency construct that is even lower-level than STS (STS currently uses it internally but it isn’t exposed) and based directly on threads rather than tasks.

Exceptions are not dismissed. "Exceptions" are part of type signature. Think of Either[ErrorType, ValueType]. Because it is part of type signature, you get nice support from the language's type system.

Exceptions are part of a method’s type signature in Java, too. What Java currently lacks is the means to offer effective and general parametric polymorphism over them, i.e. to generify them. Doing so is quite possible without requiring any change to how exceptions are declared in Java. On the other hand, the pure functional approach has its own problem with errors which isn't present with Java, which is how errors are composed with other monads. For example, the types Option<Either<T, X>> and Either<Option<T>, X> are isomorphic yet not equal, and working with them require troublesome monad transformers. If and when we choose to tackle the problem of generifying exceptions (or perhaps consider another approach altogether), we would like to have the best of both.

— Ron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230314/a1f58f8a/attachment.htm>