What happens to still-running goroutines when a Go program's main function returns?

## The rule When the function `main` returns, the program terminates. The Go specification is blunt about it: program execution finishes when `main` returns, and it **does not wait for other goroutines to complete**. The process exits with status 0. That is the whole rule, but it has sharp consequences worth spelling out. ## What runs and what does not Returning from `main` normally does run `main`'s own deferred calls — the returning function is unwound like any other. What does *not* happen is any unwinding of the other goroutines: - A goroutine parked on a channel receive is simply gone. - A goroutine halfway through writing a file never reaches its `defer f.Close()`. - A goroutine that had buffered output never flushes it. - Nothing panics, nothing is logged, and the exit status is still 0. A related trap is `os.Exit`, which is more brutal still: it terminates the program immediately and does not run **any** deferred calls, not even in the calling goroutine. ## The symptom beginners hit ```go func main() { for _, h := range hosts { go check(h) // each one prints a line } // main returns here } ``` This is a program that usually prints nothing. It is not that the goroutines failed; they were never scheduled before the process died. Add a single blocking operation before the end of `main` and the output appears — which is exactly why sprinkling a sleep at the bottom of `main` is such a common and such a bad fix. A sleep is a guess: too short and you still lose output, too long and every run pays for it. It also hides the real question, which is *who is responsible for these goroutines finishing*. ## Waiting properly The runtime provides no join operation, so waiting is arranged in your own code. The simplest form uses a channel: ```go done := make(chan struct{}) go func() { check(host) close(done) }() <-done // main blocks until the goroutine closes done ``` For several goroutines, `sync.WaitGroup` is the standard counter, and for work that can fail, a channel of results or errors lets `main` both wait and collect. The principle behind all of them is the same: **whoever writes the `go` statement owns knowing when it finished**. ## The main goroutine is not otherwise special Apart from the exit rule, the main goroutine is an ordinary goroutine. It has the same growable stack, it is scheduled the same way, it can block on the same primitives. One curiosity worth knowing: `runtime.Goexit` called from the main goroutine terminates *that goroutine* without `main` returning, so the program keeps running its other goroutines — and crashes once the last one finishes, because there is nothing left to run. ## Why the language chose this An alternative design — wait for every goroutine before exiting — sounds friendlier but is worse. A single leaked goroutine blocked forever on a channel would hang every program at shutdown, and a background worker deliberately looping forever would make clean exit impossible. Go instead makes process lifetime depend on exactly one thing, the main goroutine, and leaves coordination to the program. Shutdown becomes explicit: `main` waits for what must finish, and everything else is genuinely disposable. ## What an interviewer is checking That you know the rule, that you do not reach for `time.Sleep` as a synchronisation tool, and that you can say what you would wait on instead. Being able to describe the failure mode — output silently missing, deferred cleanup silently skipped, exit status still 0 — shows you have actually been bitten by it.