Reflections on Structured Concurrency

[Eric Kolotyluk]

Just thinking out loud here...

When I first started playing with Project Loom, I was under the impression
that Structured Concurrency was already well defined, but now I am learning
differently. I had just assumed that try-with-resources was enough to
implement it, but now I appreciate things are not so simple. For example, I
wrongly assumed that exception handling would "just work," but thinking
about why we need to call join() before calling close(), I now appreciate
the exception handling issues better. I now have more insight into the
limitations of Java try-catch-finally... Before try-with-resources, it
really ticked me off having to catch I/O Exceptions in the finally-block...

Years ago when I started using Akka/Scala, there was an emerging pattern
for Structure Concurrency, and today we have Part 1: Actor Architecture
<https://doc.akka.io/docs/akka/current/typed/guide/tutorial_1.html> which
structurally looks very much like what Project Loom is proposing. Now Akka
Actors are very different from Virtual Threads, indeed I hope they are
refactored someday to use Virtual Threads, but the goal of "goto-less"
structure is similar to what I read in Structured Concurrency JEP
<http://openjdk.java.net/jeps/8277129>. The "goto" story in the JEP is
really a great metaphor. In the early days of Akka, there was some
astonishing Actor Spaghetti Code that made it hard to reason clearly, and
even today I have a hard time wrapping my head around Akka's best practices
in the Actor Hierarchy.

It was very clarifying when Ron said, *"Generally, what we realized when
designing this API is that the design space for structured concurrency is
large, and there is no one right way to do it."* My sense is eventually
there will emerge some better designs, but we're just not there yet, so
it's exciting to see how people reason about this...

As a developer, I don't want to have to think too much, I want things to be
as intuitive as possible, and I want the default to be that the design is
as safe as possible. I appreciate designs that protect me from my own
stupidity. Rather, I appreciate designs that let me save my intelligence
for unique problems by dealing well with boilerplate problems. As an
architect and designer, I know how things are rarely as simple as people
want them to be.

While I have done a lot of Reactive Design and Implementation via
Akka/Scala, I am tired of writing and reading code where the intent is
obscured by a non-blocking, functional style... especially the constant
"non-blocking" anxiety worrying about things that can be latent and subtle.
Being able to write and read better code that focuses on the intent of the
solution is the main appeal that Project Loom has for me. Years ago I
played around with Delimited Continuations in Scala when it became popular.
It seriously hurt my brain.

So, I will continue to play around in my loom-lab project, trying to catch
up with my understanding of Project Loom, trying to learn the new
opportunities to use it.

Cheers, Eric