<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Eric.
<div class=""><br class="">
I watched the talk and was able to find just one valid point in it. The rest fall
<div class="">into three categories: 1. lack of familiarity with Java's features 2. lack of familiarity </div>
<div class="">with imperative composition, and 3. a misunderstanding of what it is that virtual </div>
<div class="">threads (or even the JDK in general) let you do. The points in the first two categories </div>
<div class="">are, I think, erroneous; the ones in the third category are mostly irrelevant.
<div class=""><br class="">
The first category first:<br class="">
<br class="">
1. That InheritableThreadLocals have less-than-ideal overhead is one of the<br class="">
reasons we've added ScopedValues (JEP 429), which are designed to interoperate<br class="">
well with structured concurrency.<br class="">
<br class="">
2. Interruption is as reliable as anything that can be offered in either Java or<br class="">
Scala. The mechanism could be made more friendly, but I don't think that's what<br class="">
he's talking about. It may not be as reliable as what Erlang can offer thanks<br class="">
to its special restrictions on the language.<br class="">
<br class="">
3. StructuredTaskScope does not leak threads. Closing the scope waits for all<br class="">
threads to terminate.<br class="">
<br class="">
4. StructureTaskScope's error handling isn't lossy. I think that's misunderstood<br class="">
partly because he hasn't closely looked at the API and partly because he missed<br class="">
the significance to observability of every fork running in its thread; I hope<br class="">
that significance will become clearer in JDK 21. In short, because every task<br class="">
is its own thread, it can report exceptions to interested observers with an<br class="">
observable context; as a result, the parent only needs to be made aware of<br class="">
exceptions that directly affect it, but it need not offer any additional<br class="">
assistance in observing the forks. Nothing here is lossy -- all exceptions are<br class="">
reported and the scope is always made aware of any fork exception that could<br class="">
impact it.<br class="">
<br class="">
5. The point about threads not being “type-safe†misses the fact that in Java</div>
<div class="">threads are not used via the Thread API directly, but through ExecutorService</div>
<div class="">APIT (or the new StructuredTaskScope). Something could be said about checked</div>
<div class="">exceptions, I guess, but that’s a completely separate topic, a hard one, and not </div>
<div class="">one where the asynchronous-functional approach particularly shines, either.</div>
<div class=""><br class="">
6. The TwR construct in Java does not require nesting in the form shown in the<br class="">
talk (the speaker seems unfamiliar with Java's TwR syntax). However, there is a<br class="">
good point here and that is that AutoCloseables are not composable, which<br class="">
requires work to support dynamic resources. We’re working on designing a more<br class="">
capable, and composable, interface than AutoCloseable to work in TwR, but it’s<br class="">
not super-high priority at this time. That was the only valid point I managed<br class="">
to find in the entire talk.<br class="">
<br class="">
The second category is exemplified by the speaker's mistake about the<br class="">
composability of the `race` method he presents. This is how obvious the<br class="">
composition is:<br class="">
<br class="">
<T> T withTimeout(Instant deadline, Callable<T> task) throws<br class="">
TimeoutException, InterruptedException, ExecutionException { try (var s =<br class="">
new StructuredTaskScope.ShutdownOnSuccess()) { s.fork(task); return<br class="">
s.joinUntil(deadline).result(); } }<br class="">
<br class="">
It can be composed with `race`, or any operation, anywhere in the hierarchy.<br class="">
I.e., instead of `race(tasks, deadline)` you can write `withTimeout<br class="">
(deadline, race(tasks))`.<br class="">
<br class="">
He tries to explain the "composition deficiency" he believes he detects by<br class="">
pointing out that statement composition is not a composition of values. But<br class="">
someone who thinks about functional effects should immediately see the<br class="">
theoretical error here because statement composition is not functional "Unit"<br class="">
composition, but rather monadic composition; and the monad here is reified<br class="">
where (in other words, where is the `bind`)? In the thread. When an operation<br class="">
blocks it effectively returns a monadic value to the scheduler, which exposes<br class="">
the means by which the operation be transformed and composed with, say, a<br class="">
timeout. That's why a functional effects person should immediately suspect that<br class="">
if they can't see how the transformation can be applied to Java code they must<br class="">
be missing something. Examination of the code for `race` itself would quickly<br class="">
show how this transformation can be factored out of `race` and abstracted.<br class="">
<br class="">
The final category is exemplified by the truly bizarre point about<br class="">
retries/backoff and loops. That virtual threads allow implementing retries<br class="">
using loops doesn't mean that that's what user code looks like. I would think<br class="">
this is almost too obvious to state, and yet what's shown in the talk is not<br class="">
how programming works in virtually any high-level language or any style.<br class="">
Rather, that retries can be efficiently implemented using loops simply means<br class="">
that by selecting the right building blocks we managed to avoid adding retries<br class="">
as a primitive and can allow such a general abstraction to be written in a way<br class="">
that is 1. composable with any I/O library and 2. interacts well with the<br class="">
platform's observability. That's what a win is (at least for a language). <br class="">
<br class="">
Boasting of a library where retries are primitives, they cannot compose with<br class="">
other libraries, and they do not interact well with observability is just<br class="">
puzzling in this context. Thanks to virtual threads, libraries can offer a<br class="">
truly composable and observable retry construct (because they can be<br class="">
implemented with something as simple as a loop). He further boasts that the<br class="">
implementation of a synchronous `retryWithExponentialBackoff` library routine<br class="">
won't fit on a slide, even though it would still be shorter than an<br class="">
asynchronous implementation...<br class="">
<br class="">
Having new code specificially written for one framework compose with other code<br class="">
written for that framework is a very low bar to clear, and it can only work if<br class="">
you manage to attract the ecosystem over to program with your new framework;<br class="">
virtual threads were added to Java only after a lot of people complained that<br class="">
that approach doesn't work -- it doesn't compose with the code they already<br class="">
have and requires too much rewriting, it doesn't work with their tools, and too<br class="">
many of them simply don't enjoy it. What virtual threads do, on the other hand,<br class="">
is allow writing concurrent code that composes with virtually any other simple<br class="">
synchronous code ever written and that will ever be written for the Java<br class="">
platform, and with the same observability and debuggability Java developers<br class="">
expect. We're able to do that not because we're smarter than library authors,<br class="">
but because these things require deep platform support. I think it won't be too<br class="">
long before we know whether or not our approach works.<br class="">
<br class="">
The JDK — a language and runtime platform — hasn't ever intended to eliminate<br class="">
the need for third-party libraries, nor does it now. Quite the opposite: we try<br class="">
to include as little as we can get away with. The JDK's goal is to provide the<br class="">
right building blocks. None of the features produced by Loom to date -- virtual<br class="">
threads, structured concurrency, scoped values -- could have been implemented<br class="">
by libraries, as they all required changes to the platform. They are the<br class="">
building blocks on top of which third party libraries -- including those that<br class="">
may provide "Refs" -- can be written in a way that is more composable and<br class="">
observable than was ever before possible on the Java platform. Conversely, I<br class="">
don't believe Loom has contributed any feature that could have been implemented<br class="">
in a third-party library; we've so far focused only on the primitives. <br class="">
<br class="">
Having said all that, it's important to remember that he's talking about a<br class="">
library that's aimed at programmers who like different things than Java<br class="">
programmers so much so that they use a different language, and, I'm sure at<br class="">
least some of the high-level libraries will continue to cater to those who<br class="">
aesthetically prefer the functional style in whatever language they enjoy<br class="">
programming for the Java platform. <br class="">
<br class="">
The important question that wasn't asked in the talk at all is, "how should<br class="">
high-level concurrency libraries work on top of the JDK now that we have<br class="">
virtual threads?" I think that one big difference is that thanks to the<br class="">
improved composability, high-level functionality that used to be offered by<br class="">
monolithic frameworks could now be offered, a la carte, by more focused<br class="">
libraries.<br class="">
<br class="">
As to your question, the for-yield construct is just syntax for monadic<br class="">
composition that's already built into Java's imperative composition, but as for<br class="">
`foreachPar`, I believe we can do even better. We're already working on a way<br class="">
that will lead to a structured concurrency construct that works with streams or<br class="">
something similar to it. JEP 428 explicitly states that StructuredTaskScope may<br class="">
not be the only structured concurrency construct we'll introduce.<br class="">
<br class="">
-- Ron<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 10 Mar 2023, at 22:57, Eric Kolotyluk <<a href="mailto:eric@kolotyluk.net" class="">eric@kolotyluk.net</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">
<p class=""><a href="https://www.youtube.com/watch?v=9I2xoQVzrhs" class="">The Great Concurrency Smackdown: ZIO versus JDK by John A. De Goes</a></p>
<p class="">I would recommend this presentation as interesting, worth watching.</p>
<p class="">However, I found a lot of problems with the arguments, and while John De Goes knows a few things about Loom, his knowledge is incomplete and out of date. On the other had, he does make a few interesting claims about Zio that
<i class="">might </i>be nice features in Loom some day. In particular, the for-yield structure in Scala and Zio is a very powerful structure, although can be quite cryptic to fathom, especially by the most clever in the Scala community.<br class="">
</p>
<p class="">I will withhold my other insights and questions until people respond to this, showing interest in further discussion.</p>
<p class="">Cheers, Eric<br class="">
</p>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</body>
</html>