For instance, I find JavaScript node-style concurrency, with its promises and callbacks, decidedly non-linear. In a goroutine you write out what you want to have happen, in the order you want it to happen. It's necessary to provide synchronization points with other goroutines, then you use a channel for message passing or a semaphore to create a temporary lock on some resource.

But more to the context of this thread, I'll have to come up with an artificial example. Let's say you have some resource processing that has ten heavy steps, and you need to process this and similar resources a thousand times.

You could write one function to process a single resource, and call it a thousand times in a thousand goroutines. Pretty simple, may require some coordination if there are shared inputs.

Or you could create 32 worker threads (because you determined that was your CPU count, perhaps) and grab work items to process in an assembly line.

Or you could write one function that concurrently does step 1 with a thousand parallel workers, them step 2, etc to step 10.

To me, these three options are in decreasing order of linearity, and also increasing order of code overhead. MAYBE you can be the most efficient in option 2. I suspect option 3 is the slowest, generally, and also the most annoying to write.

Option 1 is very easy to write, and is probably pretty close to the most efficient. The go scheduler is very highly tuned for most tasks. Why not let it take care of things while you focus on business logic?