When should you use time.NewTimer instead of time.After for a timeout in Go?

## The two APIs ```go func After(d Duration) <-chan Time func NewTimer(d Duration) *Timer ``` `After` is literally the convenience form: it creates a timer and returns only its channel, throwing the handle away. `NewTimer` gives you the `*time.Timer`, whose useful surface is: - the field `C <-chan time.Time` — the same one-shot channel `After` would have returned; - `Stop() bool` — prevent the timer firing; the bool reports whether it stopped a timer that had not yet fired; - `Reset(d Duration) bool` — re-arm the timer for a new duration. ## Reason one: you can stop it A timeout you no longer need is still a scheduled timer. When a function may return long before its deadline, `defer t.Stop()` releases it at once instead of leaving it pending. With `time.After` there is no handle at all, so "stop it early" is not an option you have. This matters most in the shape this leaf cares about: a long-running agent that arms a deadline for every unit of work. If the work almost always completes quickly, the timers that did not fire are pure waste, and the only way to reclaim them promptly is to hold a handle and call `Stop`. ## Reason two: you can reuse it ```go t := time.NewTimer(interval) defer t.Stop() for { select { case r := <-readings: _ = r // process the reading case <-t.C: // no reading arrived within interval } t.Reset(interval) } ``` One timer, re-armed each pass. The `time.After` version of the same loop calls `time.After(interval)` on every iteration, and each call allocates a timer plus a channel. On a hot loop that is the difference between one allocation and millions. ## Reason three: the deadline can be an overall budget Because `time.After` is re-evaluated every time the `select` executes, a `time.After` case inside a loop gives an **idle** timeout: the clock restarts whenever anything else happens. Creating the timer once, before the loop, and selecting on the same `t.C` each pass gives a **total** budget that really does expire at a fixed moment. The two are different contracts and choosing the wrong one is a classic bug. ## What is not a reason any more Older advice said `time.After` leaks. That was true in a specific sense: before Go 1.23, the timer behind `time.After` was retained by the runtime until it actually fired, so a loop creating one-minute timeouts thousands of times a second accumulated live timers and grew the heap with uptime. Go 1.23 changed this — timers and tickers that the program no longer refers to become eligible for garbage collection immediately, even when `Stop` was never called. On current Go the argument for `NewTimer` is control and allocation cost, not leakage. Saying "time.After leaks" without that qualification dates you. What still costs you on any version is a timer you *do* still reference — one held in a struct field, a map of per-item deadlines, or a pending `time.AfterFunc` whose callback must still run. Those are alive because your program keeps them alive, and only calling `Stop` and dropping the reference removes them. If a heap profile of a long-lived agent shows timer-related allocation climbing with uptime, that registry is where to look, not the individual `select`. ## Small facts worth having - `Timer.Stop` does **not** close `C`. Nothing ever closes a timer channel; `Stop` only prevents a future send. Code that ranges over `t.C` waiting for it to end will wait forever. - `Stop` returning `false` means the timer had already fired or already been stopped. - `time.Tick(d)` is the same convenience trade one level up: it wraps `time.NewTicker` and returns only the channel, so there is no `Ticker` to `Stop`. It also returns `nil` when `d <= 0`, and a receive on a nil channel never proceeds. - Creating a timer is cheap but not free; it is a runtime object placed in a per-processor timer structure, and re-arming an existing one avoids that setup.