Why send on a semaphore `chan struct{}` before the `go` statement rather than inside the goroutine?

## Two placements that look equivalent Both of these bound concurrent uploads to four: ```go // A: acquire before go for _, part := range parts { sem <- struct{}{} go func() { defer func() { <-sem }(); uploadPart(part) }() } // B: acquire inside the goroutine for _, part := range parts { go func() { sem <- struct{}{} defer func() { <-sem }() uploadPart(part) }() } ``` In both, at most four goroutines are executing `uploadPart` at any moment. The difference is **which goroutine does the waiting**, and that decides what stays bounded. ## Who blocks In A, the send runs on the goroutine executing the loop. When four permits are out, the loop itself parks on the send. Nothing further is created. The number of goroutines alive because of this loop is roughly N+1: the N holding permits, plus the loop. In B, the loop never blocks. It creates a goroutine per item as fast as it can iterate and finishes. Every created goroutine immediately parks on the same full channel. The four with permits work; the rest sit in the channel's wait queue. ## Why parked goroutines are not free A goroutine parked on a channel send occupies no OS thread and burns no CPU — that part of the intuition is right, and it is why Go can hold very large numbers of them. But it is not weightless: - Each has a stack (small at creation, but it grew to whatever the goroutine needed before parking) that cannot be reclaimed while the goroutine is alive. - Each keeps alive everything its closure captured. If the closure captures a per-item buffer, a decoded record, or a `[]byte` read from disk, the whole set is retained simultaneously — the very memory the concurrency limit was supposed to bound. - Each is runtime bookkeeping the scheduler and the garbage collector must account for, and each appears in every goroutine dump you take while debugging something else. The practical failure is not "Go cannot handle many goroutines". It is that placement B converts a bounded-concurrency limit into a limit on *active* work only, while the *retained* work scales with the input. ## When the input size decides it Over a fixed slice of two hundred items, both placements are fine and B is arguably tidier. The moment the input is a stream, a directory walk, a database cursor, or a queue that never ends, B is a memory leak in slow motion: the producer races ahead of the consumers with nothing to stop it. Placement A gives you the stall for free — the loop simply cannot get ahead of the permits. This is why "acquire before `go`" is the default advice. It is not that B is wrong; it is that A is bounded in one more dimension for the same number of characters. ## What A costs you The cost of A is that the spawning goroutine is stuck. If that goroutine also has to do something else — poll for cancellation, read from another source, respond to a shutdown signal — it cannot while it is parked on the send. The fix is not to move the acquire inside; it is to make the acquire itself abandonable: ```go select { case sem <- struct{}{}: // acquired case <-ctx.Done(): return ctx.Err() } ``` Now the loop stops spawning when the permits are exhausted *and* can still give up promptly when the caller cancels. ## What neither placement gives you Neither bounds anything about goroutines started elsewhere in the process, and neither bounds memory held by the work itself. A permit says "one more unit may run", not "one more unit may allocate a bounded amount". If units differ wildly in footprint, a count-based limit lets N large ones coincide; that is a property of counting units rather than of where the count is taken. ## Saying it in an interview The crisp answer is one sentence and one consequence: acquiring before `go` puts the blocking on the spawner, so live goroutines are bounded too; acquiring inside puts the blocking on the child, so you bound the work but retain a goroutine and its captures per input item.