Timothy Lochner

I wouldn't say waiting is an anti-pattern, but then I chose that approach for enkiTS so I guess that's already obvious. The wait approach is effective, and it simplifies the task manager (enkiTS is designed to be lightweight).

Yeah, the issue here is that we work in different worlds (You're realtime "I-know-my-task-set", I'm event driven long-live app "I-know-nothing-about-the-potential-task-set-of-the-app")

so waiting is almost always an antipattern because I don't know the work peak of the system (I have no control). So blocking a task should be avoided as much as possible. Keep it flowing, don't wait but spawn async continuations to be processed later when the data arrives

Then there's the "design argument": I want juniors to understand that data processing and business operation execution are not "algorithmic recipes" (Do this, wait for that, process that, etc) but a continuous flow of work, and as part of your work you could trigger more work

(Process input, process it in parallel, when done sum it, then serialize the result, etc)

So waiting doesn't block the flow of work, as the wait processes other tasks. There is the potential for deadlock if used incorrectly rather than spawning a dependent task though.

True

In theory true. In practice not. Again, tweets will fail here, but when I get a chance to make another diagram I will.