How do you write a non-blocking send and a non-blocking receive on a Go channel?

## The idiom Go has no `TrySend`/`TryReceive` method on channels. Both are expressed with a `select` whose only real case is the operation you want and whose `default` covers "it could not happen now". ```go // try-send select { case ch <- v: // v was handed to a waiting receiver, or copied into free buffer space default: // nobody was ready and there was no room: v was NOT sent } // try-receive select { case v, ok := <-ch: // got v; ok is false only if ch is closed default: // nothing was available: no value was taken } ``` Because `default` is reached only when the communication cannot proceed at that instant, the operation is genuinely all-or-nothing. There is no half-send and nothing is queued for later. ## When does the send case succeed? For an **unbuffered** channel, only if a receiver is already parked waiting on it. If no goroutine is sitting in a receive, a try-send always takes `default` — which surprises people who expect "send it, someone will pick it up". For a **buffered** channel, the send also succeeds when the buffer is not full. For the receive case, the mirror rules apply: a value is available if a sender is parked, if the buffer holds something, or if the channel is closed. ## The branch that matters is `default` A try-send whose `default` is empty throws the value away. This is the single most common defect built on this idiom, and it is invisible: nothing panics, nothing logs, throughput just quietly does not match input. Whatever the reason for using a non-blocking send, the `default` branch owes you one of: - **an increment of a dropped-items counter**, so the loss is measurable; - **a log line**, at a rate that does not itself become the problem; - **an alternative destination** — spill to disk, a slower path, a retry queue; - **an explicit, commented decision that dropping is correct here**. The same applies less dangerously to try-receive: an empty `default` there just means "no work this pass", which is usually fine, but only if the surrounding code actually does something else on that pass. ## Why not check first and then send? A tempting alternative is `if len(ch) < cap(ch) { ch <- v }`. This is wrong. Between the `len` call and the send another goroutine can fill the channel, and your send blocks after all — exactly the outcome you were trying to avoid. `len` and `cap` on a channel are a snapshot with no guarantee attached. The select form is atomic: the runtime decides readiness and performs the operation under the channel's lock, so there is no window between the check and the act. Any "check then act" pattern on a channel is a race; the `select` is the check *and* the act. ## The comma-ok form is a different thing `v, ok := <-ch` is often confused with a try-receive. It is not one: it **blocks**. `ok` does not report "was anything available"; it reports "was this value produced by a real send", so `ok` is false only when the channel is closed and drained. Inside a try-receive you can combine them — `case v, ok := <-ch:` — and then `ok == false` means the channel is closed, while landing in `default` means the channel is open but empty. Two distinct outcomes that are easy to conflate. ## When the idiom is right The non-blocking form earns its place where the goroutine has something better to do than wait: a loop that is already doing real work each pass and wants to pick up any pending item cheaply; a metrics or debug channel where losing a sample is preferable to slowing the hot path; a probe of a signal channel in the middle of a long computation. What it must not become is the body of a loop whose only purpose is to wait for the channel — that turns a parked, free goroutine into one that saturates a CPU core.