Timeouts, Timers and Tickers

## What `time.After` is `time.After` has the signature `func After(d Duration) <-chan Time`. Calling it starts a one-shot timer inside the Go runtime and immediately returns a receive-only channel. After roughly `d` has elapsed, the runtime delivers exactly one `time.Time` value on that channel — the time at which the timer fired — and then never sends again. The channel is never closed. The reason this shape is useful is that Go's `select` statement waits on several channel operations at once and proceeds with whichever is ready first. Turning "time has passed" into "a channel became readable" makes elapsed time just another event you can wait on alongside real work. ## The idiom ```go select { case r := <-readings: _ = r // handle the reading case <-time.After(2 * time.Second): // no reading arrived within two seconds } ``` If a value is available on `readings` first, that case runs and the `time.After` case is simply never taken. If two seconds pass first, the timeout case runs. If both become ready in the same instant, `select` picks one at random — that is `select`'s defined behaviour and it is not something you can lean on. The same pattern works for a send: `case ch <- v:` beside `case <-time.After(d):` gives you a send that gives up if no receiver appears. ## What it does NOT do This is the part juniors most often get wrong. The timeout bounds **your waiting**, not the other side's work. If a goroutine is computing a reading and you take the timeout branch, that goroutine keeps computing; nothing was cancelled, nothing was interrupted. If it later sends on an unbuffered channel with nobody left to receive, it blocks forever and you have leaked a goroutine. Bounding your own wait and actually cancelling downstream work are two separate jobs. It is also not a sleep. `time.Sleep(d)` parks the calling goroutine for `d` unconditionally. `time.After(d)` returns instantly and hands you a channel; the waiting happens in the `select`, and it can end early. And it is not a ticker. The channel yields one value, ever. Code that expects a heartbeat from `time.After` will fire once and then wait forever. ## Where the timeout restarts A subtlety worth knowing early: `time.After` is evaluated each time the `select` statement is executed. In ```go for { select { case r := <-readings: _ = r case <-time.After(2 * time.Second): return } } ``` every loop iteration calls `time.After` again and starts a **fresh** two-second window. So this means "give up after two seconds of silence", not "give up two seconds from the start". If you wanted a total budget, you must create the timer once, outside the loop, and reuse its channel. ## The cost Every call to `time.After` creates a new runtime timer and a new channel, and returns no handle, so you cannot stop the timer early — you can only ignore it. For an occasional timeout that is irrelevant. In a loop running thousands of times a second it is measurable allocation, and that is the usual reason to reach for `time.NewTimer` and reuse one timer instead. Historically it was worse than allocation: before Go 1.23 the timer created by `time.After` was retained by the runtime until it actually fired, so a hot loop using a long timeout could hold a large number of live timers. Go 1.23 made unreferenced timers collectable by the garbage collector even when they have not fired and were never stopped, so on current Go this is a cost question rather than a leak. ## Reading the value Most code writes `case <-time.After(d):` and throws the value away, but it is a real `time.Time` if you want it: `case t := <-time.After(d):` gives you the moment the timer fired. Note that timers fire *at or after* the requested duration, never before, and scheduling delay means "at or after" can be meaningfully later on a loaded machine.