Sharing by Communicating

## A send is an assignment Every channel operation in Go moves a **value**, and moving a value in Go means copying it — exactly like `b := a`, like passing an argument to a function, or like returning a result. `ch <- d` copies `d` into the channel's slot (or, when a receiver is already waiting, straight into that goroutine's variable), and `x := <-ch` copies out of it. There is no hidden reference, no boxing, no shared cell that both sides mutate. The channel's element type decides how many bytes move: a `chan Document` moves a whole `Document` struct, a `chan *Document` moves one pointer-sized word. This is the single most useful thing to know about channels as a beginner, because it is what makes the slogan work. If the send handed over a reference, every send would be a fresh opportunity for two goroutines to write the same memory, and channels would buy you nothing over a shared variable. ## What the copy reaches, and what it does not The copy is **shallow**, in exactly the sense that struct assignment is shallow: - `int`, `float64`, `bool`, `time.Time`, arrays such as `[16]byte`, and nested structs made only of those: fully duplicated. The two sides are now independent. - `string`: the header is copied, and because strings are immutable in Go there is nothing to alias — treat it as fully independent. - **slice** (`[]byte`, `[]string`, ...): the copy duplicates the header — pointer, length, capacity — but **both slices point at the same backing array**. `recv.Body[0] = 'X'` is visible to the sender, and if both goroutines touch it, that is unsynchronized shared memory again. - **map**, **channel**, **func**, **pointer** fields: the word is copied, the thing it refers to is shared. So the isolation a send gives you is only as deep as the element type. A `struct { ID int; Name string }` is genuinely handed over as an independent value. A `struct { Body []byte }` is not — it is a shared buffer with a copied wrapper around it. ## The ordering guarantee that rides along A send and its matching receive are a synchronization point: everything the sending goroutine wrote **before** the send is guaranteed visible to the receiving goroutine **after** the receive. That is why the handoff pattern is safe at all — the receiver does not need extra locking to read what the sender built. Note the word *before*: the guarantee covers writes that already happened, not writes the sender makes afterwards. ## When you send a pointer anyway Copying is not always what you want: - The struct is large and copying it in a hot loop shows up in a benchmark. - The receiver must mutate the value and the mutation must be observed by whoever holds it next. - The type is documented as not safe to copy because it embeds synchronization state. In all three cases you send a `*T`, and the moment you do, the semantics change completely: the channel copies the pointer, both goroutines can reach the same struct, and safety now rests on a **convention** — after the send, the sender stops touching the value. The compiler does not enforce that, which is why the pointer form is a handoff of ownership and the value form is a copy. Do not reach for the pointer form by reflex on size grounds alone. A small struct copy is a few machine words; sending a pointer usually forces the value to be heap-allocated instead of living in a stack frame, and it trades a cheap copy for an ownership rule a human has to remember. Measure with a benchmark before deciding it matters. ## What an interviewer is listening for They want to hear the word *copy*, then the qualifier *shallow*, then the consequence: sending a value isolates the two goroutines, sending a pointer does not — it transfers a responsibility. A candidate who says channels pass references has usually carried an assumption over from a language where every object argument is a reference, and everything else they say about channel safety will be built on that mistake.