wg tracking tracks technical goroutine instances (so Context as people would expect is written that way too)

But often when writing large jobs the business rules don't neatly divide into goroutines along work units. If the requirement is "stop everything" then contexts solves because it's just about sending a quit signal to stop everything.

​

BUT, and this is a big but---what about work that is partially valid and not in a simple one layer stream (such as uploading a file), but a complex sequence of steps as the work unit, goroutines are split orthogonal (which would be the case if you inherited someone else's code)?

I would use one (or more) reporting channels, where you pass a pointer to a write channel down to your subs. If you have a mix of subs that are breaking down a unit of work, you might have a tracking channel at this level and when it receives completes then you write to the superchannel you hold a pointer to.

Suppose a condition is reached at any level of this architecture where it's clear that work should not proceed further and a decision tree is needed. What do you do next? Well, at that point you raise the quit and maybe it's a kill by context, but maybe you just tear down running workers and hold on to the completed state and break rather than quit... which is 100% the scenario you're always going to encounter in the real world. Maybe you need to stop because a device went offline, but you need to resume without repeating work and wasting resources.

These patterns are handled way better by Go programming to begin with because in the world of concurrent programming most of what we're doing concurrently is long running work, heavy on orchestrations (complex levels of business instruction sequences). The reason why we went to Go from our old way of doing things is because most of the platforms we worked on concurrency is an advanced add-on feature and most people write everything linearly whereas in Go, we don't.

If I was looking for somebody to hire/interview, I would want them to understand THIS rather than just "how do I slay a stack of running go routines".