Share by
communicating.

The traditional way to do concurrency is shared memory plus locks: many threads read and write the same variables, and you guard them with mutexes so they don't clobber each other. It works, but it's notoriously error-prone — forget a lock and you get a race; take locks in the wrong order and you deadlock; and the bugs are non-deterministic, appearing only under load. Go takes a deliberately different stance, summarized in its famous motto: "Don't communicate by sharing memory; share memory by communicating."

Instead of many threads poking at shared state behind locks, Go has independent goroutines that pass data to each other through channels. Ownership of a value moves along the channel from sender to receiver, so at any moment one goroutine is working with it — no simultaneous access to guard. The synchronization is baked into the send and receive operations themselves, so you often need no explicit locks at all. This is Go's whole concurrency philosophy (borrowed from a model called CSP): make the communication the primitive, and safety follows from it. Everything else — how cheap goroutines are, how channels block — serves that idea.

A goroutine is a lightweight thread managed by the Go runtime, not the operating system. You start one by writing go f() — that's the entire syntax — and it runs concurrently with everything else. The magic is how cheap they are: a goroutine begins with a tiny stack of a few kilobytes that grows on demand, and the Go scheduler multiplexes many thousands of goroutines onto a small pool of real OS threads.

That cheapness changes how you design. Spawning an OS thread per task caps you at a few thousand before memory and context-switching overhead crush the machine; goroutines let you run hundreds of thousands comfortably. So in Go you don't ration concurrency — you use it liberally: a goroutine per incoming request, per connection, per background job, per item in a fan-out. The scheduler handles parking a goroutine that's blocked (say, waiting on a channel or I/O) and running another on that thread, so blocked goroutines cost almost nothing. The mental shift is that concurrency is abundant, which is exactly what makes the channel-based style practical: you can afford to give every unit of work its own goroutine and let channels coordinate them.

A channel is a typed pipe: one goroutine sends a value in, another receives it out. The crucial property — the thing you must internalize — is when an operation blocks, and that depends on the channel's buffer capacity.

An unbuffered channel (capacity 0) has no storage, so a send can't complete until someone is there to receive — the two operations happen together as a rendezvous, which hands you synchronization for free (the sender knows the receiver got it). A buffered channel (capacity N) can hold up to N values, so sends succeed immediately while there's room and only block when the buffer fills; receives block only when it's empty. The choice is a design decision: use unbuffered when you want sender and receiver to march in lockstep, and buffered when you want to decouple them — let a fast producer get ahead of a slower consumer by a bounded amount. Everything about coordinating goroutines reduces to picking capacities and understanding these blocking conditions.

A send blocks exactly when the buffer is full (which, for an unbuffered channel of capacity 0, is always — until a receiver takes the value); a receive blocks when the buffer is empty:

Unbuffered (cap 0): len ≥ 0 is always true, so a send always waits for a receiver. Buffered (cap 2): first two sends don't block; the third does.

A deadlock is when a blocked operation has no counterpart that can ever unblock it — a send with no receiver, or a receive with no sender:

The classic beginner deadlock: send on an unbuffered channel with no goroutine receiving → "all goroutines are asleep - deadlock!". The runnable version below models channels, blocking, and deadlock detection.

A deadlock is when goroutines are all blocked waiting on each other and none can move — and Go is unusually helpful here: its runtime detects the case where every goroutine is asleep and panics with fatal error: all goroutines are asleep - deadlock! rather than hanging silently. The most common cause is the beginner mistake of sending on an unbuffered channel with nothing set up to receive:

The unifying cure is understanding the blocking rules well enough to guarantee every blocking operation has a partner. Send on an unbuffered channel? Make sure a receiver is running (usually in another goroutine). Range over a channel? Make sure someone close()s it when done, so the loop can end. Reading from N workers? Know how many values will arrive. Deadlocks aren't mysterious in Go — they're the direct, mechanical consequence of a blocked operation with no counterpart, which is why internalizing "when does this block?" is the entire skill. The runtime's deadlock detector turns what would be a silent hang in other languages into a loud, immediate error, which is a genuine gift once you learn to read it.

The first is the goroutine leak. Goroutines are so cheap that it's easy to start one that blocks forever — waiting on a channel that never receives another value, say — and never notice. It doesn't crash; it just sits there holding memory and whatever it referenced, and in a long-running server these accumulate until you're out of memory. Every goroutine you start needs a guaranteed way to finish (a closed channel, a context cancellation, a done signal). "Cheap to start" does not mean "free to abandon."

Two more. Assuming buffered means non-blocking: a buffered channel only defers blocking until the buffer fills — size it wrong and you still block, or worse, you paper over a producer/consumer imbalance that then bites under load. And reaching back for shared memory and mutexes out of habit: Go has sync.Mutex and sometimes it's the right tool (protecting a simple counter, say), but defaulting to shared-state-plus-locks throws away the whole point of the channel model and reintroduces exactly the race conditions Go was designed to avoid. Prefer communicating over sharing until you have a concrete reason not to. The payoff for learning the model is large: concurrency, the thing that terrifies people in other languages, becomes a set of small, composable, mechanically-reasoned pieces. The whole handbook is one question you can now always answer — when does this send or receive block? — and from that, safe concurrency follows.