
`select` lets a goroutine wait on multiple channel operations at once. It blocks until one case can proceed, then executes it. If multiple cases are ready simultaneously, one is chosen at random.

<ExamplePair>
<ExampleProse>

Two goroutines each send to their own channel after a short delay. `select` receives whichever message arrives first.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "time"
)

func main() {
    c1 := make(chan string)
    c2 := make(chan string)

    go func() {
        time.Sleep(1 * time.Second)
        c1 <- "one"
    }()
    go func() {
        time.Sleep(2 * time.Second)
        c2 <- "two"
    }()

    for i := 0; i < 2; i++ {
        select {
        case msg1 := <-c1:
            fmt.Println("Received", msg1)
        case msg2 := <-c2:
            fmt.Println("Received", msg2)
        }
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

A `default` case makes `select` non-blocking - if no channel is ready it falls through to `default` immediately:

</ExampleProse>
<ExampleCode>

```go
select {
case msg := <-messages:
    fmt.Println("received message", msg)
case sig := <-signals:
    fmt.Println("received signal", sig)
default:
    fmt.Println("no activity")
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

A nil channel in a `select` case is permanently blocked - it is never selected. This lets you disable a case at runtime without restructuring the `select`:

</ExampleProse>
<ExampleCode>

```go
var retry <-chan time.Time // nil - never fires

for {
    select {
    case result := <-work:
        fmt.Println("got result:", result)
        retry = nil // success: disable retry
    case <-retry:
        fmt.Println("retrying...")
    case <-time.After(5 * time.Second):
        retry = time.After(500 * time.Millisecond) // enable retry
    }
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
A nil channel in a `select` case is permanently blocked - it is never selected. This is a useful pattern to disable a case at runtime without restructuring the `select`. Use it to "turn off" a retry branch once a success is received, or to drain a done channel before re-enabling a work channel. When multiple cases are ready simultaneously, `select` picks one at random - do not rely on ordering for correctness.
</InProduction>


Wait on multiple channel operations simultaneously - select proceeds with whichever case is ready first.

Select


Timeouts in Go are built on `select` and channels. `time.After(d)` returns a channel that sends after duration `d` - combine it with a `select` to bail out if an operation takes too long.

<ExamplePair>
<ExampleProse>

Wait up to one second for a result. If the result does not arrive in time, the `time.After` case fires and the program continues without it.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "time"
)

func main() {
    c1 := make(chan string, 1)
    go func() {
        time.Sleep(2 * time.Second)
        c1 <- "result 1"
    }()

    select {
    case res := <-c1:
        fmt.Println(res)
    case <-time.After(1 * time.Second):
        fmt.Println("timeout 1")
    }

    c2 := make(chan string, 1)
    go func() {
        time.Sleep(2 * time.Second)
        c2 <- "result 2"
    }()

    select {
    case res := <-c2:
        fmt.Println(res)
    case <-time.After(3 * time.Second):
        fmt.Println("timeout 2")
    }
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

For cancellable timeouts - where you want to clean up the timer if the operation succeeds - use `time.NewTimer` with explicit `Stop`:

</ExampleProse>
<ExampleCode>

```go
timer := time.NewTimer(2 * time.Second)
defer timer.Stop() // cancel if we return early

select {
case result := <-work:
    fmt.Println("got result:", result)
case <-timer.C:
    fmt.Println("timed out")
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

For network requests and service calls, `context.WithTimeout` is the standard approach - it propagates the deadline through the entire call stack:

</ExampleProse>
<ExampleCode>

```go
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

req, _ := http.NewRequestWithContext(ctx, http.MethodGet, "https://example.com", nil)
resp, err := http.DefaultClient.Do(req)
if err != nil {
    // errors.Is(err, context.DeadlineExceeded) is true on timeout
    fmt.Println("request failed:", err)
    return
}
defer resp.Body.Close()
```

</ExampleCode>
</ExamplePair>

<InProduction>
Always set timeouts on outbound network calls. The zero-timeout default in `net/http` has caused countless production incidents where a slow downstream service held goroutines open indefinitely. Use `http.Client{Timeout: ...}` or wrap requests in a context with deadline via `context.WithTimeout`. `time.After` leaks a timer if the channel is never drained and the timeout never fires - prefer `time.NewTimer` with `Stop()` in long-running loops or hot paths to avoid timer accumulation.
</InProduction>


Bound how long you wait for a channel operation using time.After or context.WithTimeout inside a select.

Timeouts


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.