Go, End to End

Channels

A channel is a typed pipe: one goroutine sends a value in, another receives it out. It's Go's primary tool for goroutines to communicate safely, and it's built into the language itself rather than being a library on top of threads.

Unbuffered vs buffered

An unbuffered channel (`make(chan int)`) has no internal storage. A send blocks until a receiver is ready to take the value, right at that instant, this is called a rendezvous: sender and receiver briefly synchronize. A buffered channel (`make(chan int, 3)`) has room for a fixed number of values, a send only blocks once the buffer is full, and a receive only blocks once the buffer is empty.

go · live, editable, runnable

package main import "fmt" func main() { unbuffered := make(chan string) go func() { unbuffered <- "hello" // blocks here until main receives below }() fmt.Println(<-unbuffered) buffered := make(chan string, 2) buffered <- "a" // doesn't block, buffer has room buffered <- "b" // still doesn't block, buffer now full fmt.Println(<-buffered, <-buffered) }

select

`select` waits on multiple channel operations at once, and proceeds with whichever one is ready first. If more than one is ready simultaneously, Go picks one at random, deliberately, so you don't accidentally rely on an ordering that was never guaranteed.

go · live, editable, runnable

package main import ( "fmt" "time" ) func main() { c1 := make(chan string) c2 := make(chan string) go func() { time.Sleep(50 * time.Millisecond) c1 <- "from c1" }() go func() { time.Sleep(100 * time.Millisecond) c2 <- "from c2" }() for i := 0; i < 2; i++ { select { case msg1 := <-c1: fmt.Println(msg1) case msg2 := <-c2: fmt.Println(msg2) } } }

Add a `default` case to a `select`, and it becomes non-blocking: if no channel operation is immediately ready, `default` runs instead of waiting. That's the standard way to write "check this channel, but don't wait around if there's nothing there".

select {
case msg := <-ch:
	fmt.Println("got:", msg)
default:
	fmt.Println("nothing ready right now")
}

Closing channels

`close(ch)` signals that no more values will ever be sent. Receivers can keep draining any values still buffered, but once the channel is fully drained, further receives return the zero value immediately instead of blocking. The two-value receive form (`v, ok := <-ch`) tells you which situation you're in: `ok` is `false` once the channel is closed and drained.

go · live, editable, runnable

package main import "fmt" func main() { ch := make(chan int, 3) ch <- 1 ch <- 2 ch <- 3 close(ch) for { v, ok := <-ch if !ok { fmt.Println("channel closed and drained") break } fmt.Println("received:", v) } }

Only the sender should ever close a channel, never the receiver, and never close a channel more than once (that panics). If multiple goroutines might send on the same channel, closing gets genuinely tricky, and often the cleanest fix is a separate 'done' channel purely for the shutdown signal instead of closing the data channel itself.

A `range` loop over a channel is the idiomatic way to drain it until closed, it does exactly the `v, ok := <-ch; if !ok { break }` dance above, automatically:

for v := range ch { // exits automatically once ch is closed and drained
	fmt.Println(v)
}

The nil channel gotcha

An uninitialized channel variable (`var ch chan int`) is `nil`, and both sending to and receiving from a nil channel block forever, not panic, just block, permanently. This is occasionally useful on purpose (disabling a `select` case by nilling out its channel), but it's a real footgun when it happens by accident, usually from forgetting to initialize a channel field with `make` before using it.

go · live, editable, runnable

package main import "fmt" func main() { var ch chan int // nil, never initialized with make fmt.Println("about to receive from a nil channel, this will hang") <-ch // blocks forever, this program never finishes on its own fmt.Println("this line never runs") }

Choosing between them at a glance

Unbuffered: use when you want a hard synchronization point, the sender genuinely should wait until the receiver is ready, not just fire-and-forget.
Buffered: use when the sender should be able to get a bit ahead of the receiver without blocking, a small, deliberate amount of slack, not an unbounded queue.
Never use an unbounded buffer size as a substitute for proper backpressure, a channel is not a magic infinite queue, and a producer that outpaces its consumer forever will eventually exhaust memory regardless of buffer size.

Try it yourself: fix the nil channel hang›

The example above hangs forever. Fix it by initializing the channel with make and sending a value from a goroutine before the receive:

go · live, editable, runnable