There is no error here, just a closed channel (e.g. finished successfully is indistinguishable).

You do need to use either two channels (horrible code) or some kind of Result{T,error} wrapper (bad language design).

Whenever I used channels in Go, I regretted it at the end. Always have to look up "what happens when I do x and the channel is closed" kind of stuff. Code becomes weird with all the selects and shit.

I like sync primitives and good old collections.

Oh absolutely, whenever i use anything, I have to see how to integrate cancellation and now context is everywhere just for this.

It gets overly verbose because of "simplicity"

Yeah, where I worked we rarely used channels directly in business logic. Most of our code looked like "do 5 different time consuming operations, some of them optional i.e can fail" and then combine them all appropriately depending on success/failure so we simply made a BoundedWaitGroup primitive using sync.WaitGroup and a channel to ensure the boundedness that gets used everywhere.