Wow, thank you for your really helpful reply, and your thoughts on the matter of concurrency and the various approaches.

I would wonder if pipelines, and Kafka style and functional reactive programming and reactive designs could be adapted to be async.

I would love to know how you would approach the design of a fiber application.

From my limited understanding of fibers, I would start by drawing a diagram, probably a tree or graph of all the components and draw links between the connections between fibers and components.

From what I understand of the code, you can send fibers to other fibers with the "<<" operator.

This reminds me of Golang's channels and send and receive operators on channels.

I notice the use of the word "spin" to "create a fiber" which seems to be an analogy of fibers being literal fibers or strings that are attached to eachother and "pull" and "push".

I asked the following two questions on Stackoverflow.

What's the most efficient way to fork and join control flow multiple times in a multithreaded program?

https://stackoverflow.com/questions/75866966/whats-the-most-...

A while back I was trying to understand Python's asyncio and I asked this question:

What's the canonical approach to creating multiple producers and consumers with coroutines in python asyncio? https://stackoverflow.com/questions/74420108/whats-the-canon...

I feel that wiring up asynchronous system components is kind of not ideal because you have dependencies have to refer to eachother and you don't want to solidify dependencies because you might want to reuse components.

This article highlights that problem of wiring up coroutines/fibers in the right order and which side refers to which. https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

I wonder if there could be a pattern where every fiber receives a sequence of fibers that "configure" the fiber, like a calling convention of a method, this way runtime configuration can be separate from the definition of asynchronous an pipeline.

In my original code sample, my code refers to the children tasks. In your code sample, the parent refers to the children tasks. This seems to be a property of structured concurrency.