This code is not good. Sleep loops are suspect in any language, and especially in Go. If you need to merge N channels into 1, create 1 new channel then launch N goroutines that all read from their own channel and write to the one new channel. Also, slice.Delete is O(N) and must not be used in a loop: that’s O(N^2). On top of all of that, Goroutines are too slow to improve performance for numeric code. They help with network code and IO, and if you’re lucky, you can run different CPU bound tasks in different goroutines and get a speed up. Sending small batches of work like this is bad. You can do it for illustrative purposes, but in that case, you need to know how to actually fan goroutines, and not use a sleep loop!
Frankly this is a mess. Why are there so many channels? If you want to fan out, it is much cleaner, simpler and less error prone to have a single work queue and N worker goroutines that “steal” work from it, posting back the results.
In addition, it makes the best available use of worker resources to “work steal” because workers that are completing faster tasks can get through more of the queued items while other workers are busy processing slower tasks.
If you try to subdivide the work up front by creating a channel for each worker and splitting the items across them, and some work takes longer than others, then you are guaranteed to end up stuck with workers sat idle because “their” work is done but others are still busy.
Very minor point, but this has come up a dozen times since Go 1.18 was released:
we want to write a program which is concurrent, does not share memory, and nowadays - might use polymorphism.
It seems like lately everyone thinks polymorphism == parametric polymorphism, but Go interfaces are polymorphic, right (subtype polymorphism)? As are first class functions (i.e., two different closures with the same signature can be passed into an argument whose type is a function with the same signature)?
This code is not good. Sleep loops are suspect in any language, and especially in Go. If you need to merge N channels into 1, create 1 new channel then launch N goroutines that all read from their own channel and write to the one new channel. Also, slice.Delete is O(N) and must not be used in a loop: that’s O(N^2). On top of all of that, Goroutines are too slow to improve performance for numeric code. They help with network code and IO, and if you’re lucky, you can run different CPU bound tasks in different goroutines and get a speed up. Sending small batches of work like this is bad. You can do it for illustrative purposes, but in that case, you need to know how to actually fan goroutines, and not use a sleep loop!
Frankly this is a mess. Why are there so many channels? If you want to fan out, it is much cleaner, simpler and less error prone to have a single work queue and N worker goroutines that “steal” work from it, posting back the results.
Example: https://go.dev/play/p/r2d--RW6L_T
In addition, it makes the best available use of worker resources to “work steal” because workers that are completing faster tasks can get through more of the queued items while other workers are busy processing slower tasks.
If you try to subdivide the work up front by creating a channel for each worker and splitting the items across them, and some work takes longer than others, then you are guaranteed to end up stuck with workers sat idle because “their” work is done but others are still busy.
Very minor point, but this has come up a dozen times since Go 1.18 was released:
It seems like lately everyone thinks polymorphism == parametric polymorphism, but Go interfaces are polymorphic, right (subtype polymorphism)? As are first class functions (i.e., two different closures with the same signature can be passed into an argument whose type is a function with the same signature)?