Temporal coupling in Fibers and Fibers vs State Machines.

[Thomas May]

> Martin's concerns are, if by composition he means what I think he means, if
you could set up pieces of computation and functionality and combine them
into larger components. If so, these components can have state and those
state could change in response to stimuli from other components. Reactive
is one of such approach that has individual pieces - operators chained up
on a dataflow have internal state tracking when and how their peers can
send data and commands to each other. Loom's, and Kotlin's Coroutines
instead say you compose via the source code itself, by writing larger and
larger methods encompassing a lot of imperative operations. If you have
such a method, but for some uses need some retry code, you may be out of
luck and have to code yet another set of methods to include that
functionality.

I believe the concerns are more that things like "CompletableFutures" are hard to intuitively
compose correctly.

For example, think of a graph of Futures.  Now imagine you want to conditionally traverse the graph
based on node the values returned by each future and cancel the rest based on some condition.

With CompletableFutures and traditional threads, that's really difficult without introducing a lot of blocking
on some thread.  In fact, it's pretty much impossible using the composition methods available.  You are
forced to call `.join()`.  This is isn't so bad with loom backed completable future but it is a killer for the standard FJP.

On the flip side, async/await syntax handles this sort of thing pretty much right out of the box. The awaits all
allow the current thread to go do something else useful and, as a bonus, are pretty easy to read.  The
downside is the colored function problem.

I believe that is where the composition statement comes into play.  Futures and promises are hard
to compose correctly.  They end up looking ugly and hard to read.  Loom helps here, but ultimately,
it means you have to start caring at a function level "Is this running on a fiber pool or a regular pool".
If the answer is a regular pool, you run serious risks calling .join() if your code is also executing within the same pool.

Just my two cents.

I still like the loom approach simply because it eliminates the colored function problem without adding
extra cognitive burden.

________________________________

NOTICE: This e-mail message, together with any attachments, contains information of Clearwater Analytics and/or its affiliates that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately delete it. The information we provide is from sources Clearwater Analytics considers reliable, but Clearwater Analytics provides no warranties regarding the accuracy of the information. Further, nothing in the email should be construed as legal, financial, or tax advice, and any questions regarding the intended recipient's individual circumstances should be addressed to that recipient's lawyer and/or accountant.

Clearwater Analytics, 777 W. Main St, Boise, ID 83702
If you prefer not to receive emails from Clearwater Analytics you may unsubscribe<http://clearwater-analytics.com/unsubscribe>.