
Channels can synchronize execution across goroutines. A goroutine signals it is done by sending a value (or closing) a channel - the main goroutine blocks on a receive until the signal arrives.

<ExamplePair>
<ExampleProse>

Launch a goroutine that does some work and signals completion via a `done` channel. The main goroutine blocks on `<-done` until the worker sends.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "time"
)

func worker(done chan bool) {
    fmt.Println("working...")
    time.Sleep(time.Second)
    fmt.Println("done")
    done <- true
}

func main() {
    done := make(chan bool)
    go worker(done)
    <-done // block until worker signals
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

When one goroutine needs to signal many others at once (called fan-out), close the channel instead of sending N values. A close broadcasts to all receivers.

</ExampleProse>
<ExampleCode>

```go
done := make(chan struct{})

for i := 0; i < 3; i++ {
    go func(id int) {
        fmt.Printf("worker %d started\n", id)
        <-done // each worker waits for the close
        fmt.Printf("worker %d shutting down\n", id)
    }(i)
}

time.Sleep(100 * time.Millisecond)
close(done) // broadcast to all three goroutines
time.Sleep(100 * time.Millisecond)
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

For joining N goroutines each doing independent work, collecting results via a channel can replace `sync.WaitGroup`.

</ExampleProse>
<ExampleCode>

```go
results := make(chan int, 5) // buffered so goroutines don't block

for i := 1; i <= 5; i++ {
    go func(n int) {
        results <- n * n
    }(i)
}

sum := 0
for i := 0; i < 5; i++ {
    sum += <-results
}
fmt.Println("sum of squares:", sum) // 55
```

</ExampleCode>
</ExamplePair>

<InProduction>
The done channel pattern (close a `chan struct{}` to broadcast cancellation to multiple goroutines) predates the `context` package and is still common in library code. Prefer `context.Context` in new application code - it composes cancellation, deadlines, and values in one type that the whole standard library understands. `chan struct{}` uses zero memory per item and signals intent clearly: this channel carries no data, only timing.
</InProduction>


Use channels as done signals to wait for goroutines to finish before continuing.

Channel Synchronization


When passing a channel to a function, you can constrain its direction: `chan<- T` is send-only, `<-chan T` is receive-only. The compiler enforces the constraint - misuse is a compile error, not a runtime panic.

<ExamplePair>
<ExampleProse>

Without direction constraints, any function could accidentally receive from a channel meant only for sending, or send to one meant only for receiving. Here, `ping` is a pure sender and `pong` is a relay - it receives from one channel and forwards to another. Restricting each function to only the direction it needs makes the mistake a compile error instead of a silent bug.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func ping(pings chan<- string, msg string) {
    pings <- msg
}

func pong(pings <-chan string, pongs chan<- string) {
    msg := <-pings
    pongs <- msg
}

func main() {
    pings := make(chan string, 1)
    pongs := make(chan string, 1)

    ping(pings, "passed message")
    pong(pings, pongs)
    fmt.Println(<-pongs) // "passed message"
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

A bidirectional `chan T` is assignable to `chan<- T` or `<-chan T` without a cast - the compiler inserts the narrowing automatically:

</ExampleProse>
<ExampleCode>

```go
ch := make(chan int)

var send chan<- int = ch   // valid: narrowing to send-only
var recv <-chan int = ch   // valid: narrowing to receive-only

// send = recv  // compile error: <-chan int is not assignable to chan<- int
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

A function can also return a directional channel. The return type `<-chan int` tells callers they may only receive - they cannot accidentally send to or close the internal channel. The body below is a mock of a real producer pattern (streaming events, reading from a database); the important part is the return type signature, not the loop internals.

</ExampleProse>
<ExampleCode>

```go
func generate(done <-chan struct{}) <-chan int {
    out := make(chan int)
    go func() {
        defer close(out)
        for i := 0; ; i++ {
            select {
            case out <- i: // in production: emit a db row, event, generated ID, etc.
            case <-done:   // caller signals stop - goroutine exits and closes out
                return
            }
        }
    }()
    return out // returns immediately; goroutine keeps running in background
}

func main() {
    done := make(chan struct{})
    nums := generate(done)

    fmt.Println(<-nums) // 0
    fmt.Println(<-nums) // 1
    fmt.Println(<-nums) // 2

    close(done) // built-in: unblocks any goroutine waiting on <-done, signaling it to stop
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Directional channel types are documentation enforced by the compiler. A function that accepts `chan<- T` cannot accidentally receive from it, and a function accepting `<-chan T` cannot close it (only the sender should close). Use them in public APIs to make data flow explicit and prevent misuse by callers. The discipline also helps readers understand a function's role at a glance: a `<-chan` parameter means "this is a consumer", a `chan<-` parameter means "this is a producer".
</InProduction>


Restrict channels to send-only or receive-only in function signatures to document and enforce data flow.

Buffered channels accept sends without a waiting receiver - a bounded queue between goroutines.