sync.WaitGroup

Canonical guidance

• call Add before go
• defer Done at the start of the goroutine
• keep one clear owner for launch and one clear wait point
• on newer Go versions, consider WaitGroup.Go when it makes launch ownership simpler

Use when

• waiting for sibling goroutines
• bounded background work
• simple fan-out without error propagation

Avoid

• calling Add inside the goroutine
• copying a WaitGroup
• mixing it with ad hoc shutdown rules nobody owns

Preferred pattern

var wg sync.WaitGroup

for _, job := range jobs {
	wg.Add(1)
	go func(job Job) {
		defer wg.Done()
		process(job)
	}(job)
}

wg.Wait()

Anti-pattern

• racing Wait against Add because work registration happens after launch

Explanation: This anti-pattern is tempting because the goroutine already “knows” it exists, but WaitGroup correctness depends on registration happening first.

Why

• WaitGroup is simple only when lifecycle ownership stays simple