
Sorting is a fundamental operation on collections. Go provides generic sorting via slices.Sort (Go 1.21+) for types with a natural order, slices.SortFunc for custom comparison logic, and sort.Search for binary search on already-sorted collections.

<ExamplePair>
<ExampleProse>

Sort a slice of integers in ascending order using slices.Sort. This is the generic, type-safe replacement for the older sort.Ints and sort.Slice functions.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "slices"
)

func main() {
    nums := []int{3, 1, 4, 1, 5, 9, 2, 6}
    slices.Sort(nums)
    fmt.Println(nums) // [1 1 2 3 4 5 6 9]

    // Sort in descending order using slices.SortFunc
    slices.SortFunc(nums, func(a, b int) int {
        return b - a // reverse comparison
    })
    fmt.Println(nums) // [9 6 5 4 3 2 1 1]
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Sort strings - slices.Sort handles strings as well as any type with a natural order. Sort in reverse with slices.Reverse (Go 1.21+).

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "slices"
)

func main() {
    words := []string{"zebra", "apple", "mango"}
    slices.Sort(words)
    fmt.Println(words) // [apple mango zebra]

    slices.Reverse(words)
    fmt.Println(words) // [zebra mango apple]
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Binary search on a sorted slice with sort.Search or slices.BinarySearch. search.Search returns the index where the element would be inserted; slices.BinarySearch (Go 1.21+) returns the index and a bool indicating exact match.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "slices"
    "sort"
)

func main() {
    sorted := []int{1, 2, 3, 5, 8, 13}

    // slices.BinarySearch (Go 1.21+)
    idx, found := slices.BinarySearch(sorted, 5)
    fmt.Println(idx, found) // 3 true

    // sort.Search (returns insertion point)
    idx = sort.Search(len(sorted), func(i int) bool {
        return sorted[i] >= 8
    })
    fmt.Println(idx) // 4
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Prefer slices.Sort and slices.SortFunc (Go 1.21+) for new code - they are generic, type-safe, and measurably faster than sort.Slice. sort.Search is a stable binary search that works on any sorted collection; reach for it instead of linear scans in hot paths (log(n) vs n). Note that slices.Sort is not stable - equal elements may not retain their original order. Use slices.SortStableFunc if you need to preserve the original order of equal elements (e.g., sorting by priority then by creation time for display).
</InProduction>


Sorting slices with slices.Sort (generic, Go 1.21+), slices.SortFunc for custom order, and sort.Search for binary search.

Sorting


Sorting by functions enables custom comparison logic - sorting structs by specific fields, multi-key sorting (primary then secondary), or business-specific orderings. slices.SortFunc accepts a less-than function; the cmp package provides comparison helpers for composing multi-key sorts.

<ExamplePair>
<ExampleProse>

Sort a slice of structs by a specific field using slices.SortFunc. The comparison function receives two elements and returns a negative, zero, or positive int indicating less-than, equal, or greater-than.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "slices"
)

type Person struct {
    Name string
    Age  int
}

func main() {
    people := []Person{
        {"Alice", 30},
        {"Bob", 25},
        {"Charlie", 35},
    }

    // Sort by age (ascending)
    slices.SortFunc(people, func(a, b Person) int {
        return a.Age - b.Age
    })
    fmt.Println(people)
    // [{Bob 25} {Alice 30} {Charlie 35}]
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Multi-key sort: sort by primary field, then by secondary field for ties. Use the cmp.Compare helper to chain comparisons - if the first comparison is non-zero, return it; otherwise move to the next key.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "cmp"
    "fmt"
    "slices"
)

type Task struct {
    Priority int
    CreatedAt int64
    Title    string
}

func main() {
    tasks := []Task{
        {1, 100, "Fix bug"},
        {1, 50, "Add feature"},
        {2, 75, "Review PR"},
    }

    // Sort by priority (ascending), then by CreatedAt (ascending) for ties
    slices.SortFunc(tasks, func(a, b Task) int {
        if cmp := cmp.Compare(a.Priority, b.Priority); cmp != 0 {
            return cmp
        }
        return cmp.Compare(a.CreatedAt, b.CreatedAt)
    })

    for _, t := range tasks {
        fmt.Printf("%d %d %s\n", t.Priority, t.CreatedAt, t.Title)
    }
    // 1 50 Add feature
    // 1 100 Fix bug
    // 2 75 Review PR
}
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Stable vs unstable sort: slices.Sort and slices.SortFunc are unstable (equal elements may not retain their original order). Use slices.SortStableFunc to preserve the original order of equal elements when secondary keys matter for presentation.

</ExampleProse>
<ExampleCode>

```go
package main

import (
    "fmt"
    "slices"
)

type Item struct {
    Category string
    Order    int
}

func main() {
    items := []Item{
        {"A", 1},
        {"B", 2},
        {"A", 3},
    }

    // Unstable sort by category: items within "A" may reorder
    unstable := slices.Clone(items)
    slices.SortFunc(unstable, func(a, b Item) int {
        if a.Category < b.Category {
            return -1
        } else if a.Category > b.Category {
            return 1
        }
        return 0
    })
    fmt.Println("Unstable:", unstable)

    // Stable sort: items within "A" retain their original order
    stable := slices.Clone(items)
    slices.SortStableFunc(stable, func(a, b Item) int {
        if a.Category < b.Category {
            return -1
        } else if a.Category > b.Category {
            return 1
        }
        return 0
    })
    fmt.Println("Stable:", stable)
}
```

</ExampleCode>
</ExamplePair>

<InProduction>
Stable sorts are critical when displaying sorted results to users - if you sort by priority then by creation time for display, an unstable sort may lose the secondary ordering, causing flickering or confusing re-orderings in UI. For backend operations (preparing data for processing), instability doesn't matter and unstable sorts are faster. Use slices.SortStableFunc when building a display payload; use slices.SortFunc for internal transformations. The cmp package helpers (cmp.Or, cmp.Compare) make multi-key sorts readable - chaining raw int comparisons with ternaries is error-prone.
</InProduction>


Custom sorting with slices.SortFunc, multi-key sorting with cmp.Compare, and stable vs unstable sort.

Sorting by Functions


Instead of sharing state protected by a mutex, you can confine state to a single goroutine and expose read and write access through channels. This pattern eliminates data races by construction: only one goroutine ever touches the state.

<ExamplePair>
<ExampleProse>

A state goroutine owns a map. Callers send command structs over channels and receive results via per-request reply channels. The state goroutine serializes all access in its `select` loop.

</ExampleProse>
<ExampleCode>

```go
package main

import "fmt"

type readOp struct {
    key  int
    resp chan int
}

type writeOp struct {
    key  int
    val  int
    resp chan bool
}

func main() {
    reads := make(chan readOp)
    writes := make(chan writeOp)

    // state goroutine: sole owner of the map
    go func() {
        state := make(map[int]int)
        for {
            select {
            case op := <-reads:
                op.resp <- state[op.key]
            case op := <-writes:
                state[op.key] = op.val
                op.resp <- true
            }
        }
    }()

    // write
    w := writeOp{key: 1, val: 42, resp: make(chan bool)}
    writes <- w
    <-w.resp

    // read
    r := readOp{key: 1, resp: make(chan int)}
    reads <- r
    fmt.Println("value:", <-r.resp) // 42
}
```

</ExampleCode>
</ExamplePair>

Compare the two approaches:

| Approach | Best for |
|---|---|
| Mutex | Simple read-modify-write; high-throughput counters |
| Stateful goroutine | Complex state transitions; protocol-like sequencing |

<ExamplePair>
<ExampleProse>

The stateful goroutine is heavier than a mutex for a plain counter but shines when state transitions follow a protocol - for example, a connection that must be in `idle` before it can move to `in-flight`:

</ExampleProse>
<ExampleCode>

```go
type connState int

const (
    idle connState = iota
    inflight
    closing
)

// transition is enforced inside the state goroutine's select,
// so callers can never put the connection into an invalid state.
```

</ExampleCode>
</ExamplePair>

<InProduction>
The stateful goroutine pattern (one goroutine owns mutable state, all access goes through a channel) avoids data races by design. It trades throughput for correctness guarantees. Use it when the state transitions are complex or when you want to model a protocol; use a mutex when the critical section is a simple read-modify-write.
</InProduction>


Confine mutable state to a single goroutine and expose it through channels to avoid data races by design.