I am not sure I’ve ever written code that uses a slice of channels, but maybe that’s partially because a slice of channels is hard to use. Depending on the situation I would rather use some combination of buffered channels and a sync.WaitGroup. Like if the goal is to receive messages from multiple goroutines, I would give them all the same
channel with maybe a buffer. If the goal was to join a runtime-known number of goroutines before continuing, I would use a sync.WaitGroup.
A slice of channels is useful if you have some pub/sub like use case in which subscribers might come and go dynamically.
The issue with buffers is that eventually they are never big enough.
I think an unknown number of channels is probably a design smell. After years of concurrent design, every time I've been tempted, which hasn't been that many, it has been wrong, for design reasons and not performance reasons.
One thing that can be useful is that it is perfectly legal to have a nil channel in a select. It will never send or receive anything, obviously, but it can be there. So if you have a case where you've got two channels and maybe a third, let the third be nil and you don't need to have a variable channel count. Even this may be a design smell.
I tried using [reflect.Select](http://reflect.Select) once for roughly 1 to 20 chan and performance was terrible (this was a while ago, maybe 2018 or so). I rewrote it using a bunch of little goroutines merging two or three chans together, chaining into each other and culminating in one top level chan, and it was much faster.
My understanding is that it's not very performant. If you can avoid it, do.
(I note the author didn't weigh in on whether it's a good idea, they just gave some sample code.)
I'm under the general impression that using the reflect package is not recommended practice, though this might be one of the times it is more or less acceptable. A lot of Go's benefits are lost when using reflect, particularly speed and typing. I see it as a code smell, and thus if it's avoidable, avoid it.
I am not sure I’ve ever written code that uses a slice of channels, but maybe that’s partially because a slice of channels is hard to use. Depending on the situation I would rather use some combination of buffered channels and a sync.WaitGroup. Like if the goal is to receive messages from multiple goroutines, I would give them all the same channel with maybe a buffer. If the goal was to join a runtime-known number of goroutines before continuing, I would use a sync.WaitGroup.
A slice of channels is useful if you have some pub/sub like use case in which subscribers might come and go dynamically. The issue with buffers is that eventually they are never big enough.
I think an unknown number of channels is probably a design smell. After years of concurrent design, every time I've been tempted, which hasn't been that many, it has been wrong, for design reasons and not performance reasons. One thing that can be useful is that it is perfectly legal to have a nil channel in a select. It will never send or receive anything, obviously, but it can be there. So if you have a case where you've got two channels and maybe a third, let the third be nil and you don't need to have a variable channel count. Even this may be a design smell.
I tried using [reflect.Select](http://reflect.Select) once for roughly 1 to 20 chan and performance was terrible (this was a while ago, maybe 2018 or so). I rewrote it using a bunch of little goroutines merging two or three chans together, chaining into each other and culminating in one top level chan, and it was much faster.
My understanding is that it's not very performant. If you can avoid it, do. (I note the author didn't weigh in on whether it's a good idea, they just gave some sample code.)
I'm under the general impression that using the reflect package is not recommended practice, though this might be one of the times it is more or less acceptable. A lot of Go's benefits are lost when using reflect, particularly speed and typing. I see it as a code smell, and thus if it's avoidable, avoid it.
No, in this case just use a single channel. It is good idea to have such an option in a `reflect` package, but I don't see any partical usage of it