Goroutine Lifecycle

## What the statement is A **goroutine** is a function executing concurrently with other goroutines in the same address space. The `go` statement is the only way to create one: ```go go check(host) ``` That single keyword turns an ordinary call into a concurrent one. The calling goroutine does not block: it proceeds to the statement after the `go` statement while `check(host)` runs somewhere else, possibly on another CPU, possibly interleaved on the same one. Every Go program already has one goroutine before it ever runs a `go` statement — the **main goroutine**, created by the runtime to run package initialisation and then `main`. Everything else descends from a `go` statement somebody wrote. ## What the operand may be The operand of `go` must be a **function or method call**. These are all legal: ```go go check(host) // ordinary function call go conn.ping() // method call go func() { check(host) }() // call of a function literal ``` These are not: - `go check` — an identifier, not a call. - `go x + 1` — an expression, not a call. - `v := go check(host)` — `go` is a statement, so it has no value to assign. That last point is the one newcomers trip on. `go` gives you nothing back. Whatever the function returns is thrown away — `go vet` will not even complain, because discarding a return value is legal Go. If the work produces a result, the goroutine has to send it somewhere: a channel, or a variable protected by a mutex. ## What it does *not* give you Compared with a thread API in most other languages, the `go` statement is deliberately bare: - **No handle.** There is no `Goroutine` object, no future, no join method. The `go` statement returns nothing at all. - **No id.** The runtime numbers goroutines internally and prints those numbers in panic dumps and profiles, but there is no supported API to read one, precisely so nobody builds goroutine-local storage on it. - **No kill.** Nothing can stop a goroutine from the outside. A goroutine ends when its function returns (or when the process exits). Stopping one early requires that it cooperate — it must be *asked*, on a channel or through a cancellable value it is watching. - **No join.** If the code that started a goroutine needs to know when it finished, it must arrange that itself: receive from a channel the goroutine closes or sends on, or use `sync.WaitGroup`. The runtime will not wait for anyone. A useful way to phrase it in an interview: `go` is cheap to write and cheap to run, and every bit of the lifecycle management that other languages hand you is left to you on purpose. ## What it costs A goroutine is not an OS thread. Starting one allocates a small runtime structure and a stack of roughly **2 KB**, which grows and shrinks on demand as the goroutine calls deeper. An OS thread typically reserves megabytes up front. The Go runtime multiplexes many goroutines onto a much smaller set of OS threads, so tens or hundreds of thousands of goroutines in one process is an ordinary design, not a stunt. Blocking a goroutine — on a channel, a mutex or network I/O — parks it and frees its thread for other goroutines rather than pinning a kernel thread. ## Evaluation order, in one line The function value and the parameters are evaluated **in the calling goroutine, at the `go` statement**; only the invocation happens in the new goroutine. So `go check(host)` snapshots `host` right there, while `go func() { check(host) }()` reads `host` later, whenever the goroutine actually runs. ## Lifetime A goroutine's lifetime is independent of the one that started it — with one blunt exception: when `main` returns, the process exits and every other goroutine dies where it stands, deferred calls unrun. Concurrency in Go is easy to start and entirely your responsibility to finish.