
A goroutine is a function executing concurrently with other goroutines in the same address space. The `go` keyword launches one. Goroutines start with a small stack (around 2-8 KB) that grows as needed, so spawning thousands is practical.

<ExamplePair>
<ExampleProse>

Prefix any function call with `go` to run it concurrently. The calling goroutine continues immediately without waiting. If `main` returns before the goroutine finishes, the goroutine is killed.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "time"
)

func say(s string) {
    for i := 0; i < 3; i++ {
        time.Sleep(50 * time.Millisecond)
        fmt.Println(s)
    }
}

func main() {
    go say("goroutine") // runs concurrently
    say("main")         // runs in the main goroutine
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Anonymous functions work too - useful for short, in-place concurrent tasks:

</ExampleProse>
<ExampleCode>

```go
go func(msg string) {
    fmt.Println(msg)
}("hello from goroutine")
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

The goroutine scheduler is co-operative with preemption points at function calls, channel operations, and system calls. GOMAXPROCS (default: number of CPU cores) controls how many goroutines run in parallel on OS threads. Use a channel or `sync.WaitGroup` to wait for goroutines to finish:

</ExampleProse>
<ExampleCode>

```go
done := make(chan struct{})
go func() {
    fmt.Println("working...")
    close(done)
}()
<-done // blocks until goroutine closes the channel
```

</ExampleCode>
</ExamplePair>

<InProduction>
Goroutines are cheap but not free. Launching one per inbound request in a high-QPS service can create millions of live goroutines under load, each holding a stack frame while blocked on I/O. Use a worker pool or semaphore to bound concurrency when processing untrusted input or calling rate-limited services. The main goroutine exiting kills all goroutines immediately - use `sync.WaitGroup` or a done channel to ensure cleanup runs before exit.
</InProduction>


Lightweight concurrent functions launched with the go keyword - the foundation of Go's concurrency model.

Goroutines


A channel is a typed conduit for values. Sending a value to a channel and receiving a value from a channel are both synchronisation points - by default, neither completes until the other side is ready.

<ExamplePair>
<ExampleProse>

Create a channel with `make(chan T)`, where `T` is the type of values it carries. Use `<-` to send (`ch <- value`) and receive (`value := <-ch`). Because sending blocks until a receiver is ready, the send here must happen in a goroutine - otherwise `main` would freeze waiting for itself.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func main() {
    ch := make(chan int)

    go func() {
        ch <- 42 // send a value
    }()

    v := <-ch // receive the value
    fmt.Println(v) // 42
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

You can pass a channel to any function. Here two goroutines each send a partial sum; `main` receives both results and adds them. The two receives happen in order, but either goroutine may finish first - channels handle the coordination automatically.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

func sum(s []int, ch chan int) {
    total := 0
    for _, v := range s {
        total += v
    }
    ch <- total
}

func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    ch := make(chan int)
    go sum(s[:len(s)/2], ch) // 7+2+8 = 17
    go sum(s[len(s)/2:], ch) // -9+4+0 = -5

    x, y := <-ch, <-ch
    fmt.Println(x, y, x+y) // -5 17 12 (order may vary)
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Channels can also be used as a done signal - send when a goroutine finishes so the caller knows it is safe to continue:

</ExampleProse>
<ExampleCode>

```go
done := make(chan bool)

go func() {
    fmt.Println("working")
    done <- true
}()

<-done // wait for goroutine to finish
fmt.Println("done")
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

The arrow direction shows data flow: `ch <- v` sends `v` to `ch`, `v := <-ch` receives from `ch`. Receiving from a closed channel returns the zero value immediately with the ok flag set to false:

</ExampleProse>
<ExampleCode>

```go
ch := make(chan int, 1)
ch <- 42
close(ch)

v, ok := <-ch
fmt.Println(v, ok)  // 42 true

v, ok = <-ch
fmt.Println(v, ok)  // 0 false (channel closed, drained)
```

</ExampleCode>
</ExamplePair>

<InProduction>
An unbuffered channel send blocks until a receiver is ready - this is a synchronisation guarantee, not just communication. In tests, channels are the idiomatic way to wait for a goroutine to complete a specific action without polling or `time.Sleep`. Sending on a closed channel panics; receiving from a closed channel returns the zero value immediately. Never close a channel from the receiver side or from a goroutine that did not create it - use a dedicated closer pattern or `sync.Once` when multiple producers share one channel.
</InProduction>


Typed conduits for sending values between goroutines - channels communicate and synchronise.

Implementing the error interface with a struct to carry structured context callers can extract.