How do you merge several receive-only Go channels into one channel a consumer can range over?

## What fan-in means A Go channel has exactly one queue and any number of goroutines may send into it. Fan-in (also called merging) exploits that: you take N independent input channels and produce **one** output channel carrying every value that appeared on any of them, so a consumer can write a single `for v := range merged` loop instead of juggling N sources. The reason you need a pattern at all is that a receive expression names one channel. `for v := range a` blocks until `a` is closed, so you cannot simply loop over `a` and then over `b` — values on `b` would sit unread the whole time. ## The canonical shape ```go func merge[T any](srcs ...<-chan T) <-chan T { out := make(chan T) var wg sync.WaitGroup for _, src := range srcs { wg.Go(func() { for v := range src { out <- v } }) } go func() { wg.Wait() close(out) }() return out } ``` Three separate jobs are visible here, and interviewers probe each one. **One forwarder per source.** Each goroutine owns exactly one input. Its loop ends naturally when that input is closed and drained, which is how the merge learns that a source is finished — there is no registry, no counting of values, no polling. **A `sync.WaitGroup` counting the forwarders.** A `WaitGroup` is a counter: it goes up when work starts and down when work finishes, and `Wait` blocks until it reaches zero. `wg.Go(f)` (Go 1.25 and later) does both halves for you — it registers the work, runs `f` in a new goroutine, and deregisters when `f` returns. **A closer goroutine.** The output channel must be closed, or the consumer's range loop never ends. It must be closed **once**, and only after the last forwarder has stopped sending. No forwarder can decide that on its own: from inside one forwarder you cannot tell whether the others are still running. So the decision is moved to a goroutine whose whole job is `wg.Wait()` then `close(out)`. ## Why the merge function returns before anything is drained The merge function is a **constructor**, not a drain. On an unbuffered `out`, every forwarder blocks on its first send until somebody receives, and nobody can receive until the caller holds the channel. If the merge function waited for the forwarders itself, it would never return and the forwarders would never be released. Returning immediately, and closing asynchronously, is the only shape where producer and consumer overlap in time. ## The single-goroutine alternative You can also merge in one goroutine with a `select` over all sources. It is more code and it has a sharp edge: **a closed channel is always ready to receive**, returning the zero value immediately. A `select` loop that keeps a closed case in play therefore spins at full CPU. The fix is to assign a nil channel to that case's variable once it reports closed, because a receive from a nil channel blocks forever and so disables the case. The loop ends when every case has been nil-ed out. Since Go's `select` cannot be written over a slice of channels of unknown length without reflection, the goroutine-per-source version is what you write in practice, and it is what an interviewer expects on the whiteboard. ## Types and ownership Returning `<-chan T` rather than `chan T` is deliberate: the caller can only receive, so it cannot send into a channel it did not create nor close a channel it does not own. That is a compile-time expression of "the merge owns the output". The sources are declared `<-chan T` for the same reason: the merge only reads them. Whoever produces a source is responsible for closing it, and if a source is never closed, its forwarder never returns, `wg.Wait` never returns, and the merged channel never closes — a hang the consumer sees as a range loop that simply stops yielding. ## Adding sources later The set of sources is fixed at the moment `merge` is called. Registering another forwarder afterwards races with the closer goroutine's `Wait`. The safe way to add a late source is to merge again: `merged2 := merge(merged, newSource)`. Merges compose, because the output of a merge is just another channel. ## Buffering An unbuffered `out` is correct and is the default choice. A buffer only decouples bursts; it changes neither the ordering nor the closing rules, and it hides a slow consumer for a while instead of applying backpressure to the sources.