How to sort a slice in Go

1slices.Sort (Go 1.21+)Recommended

slices.Sort(s) sorts in place, ascending, for any element type that supports < — ints, floats, strings. No closure, no imports beyond slices, and nothing to get backwards. There is no descending variant: sort ascending and call slices.Reverse.

package main

import (
	"fmt"
	"slices"
)

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

	names := []string{"cherry", "apple", "banana"}
	slices.Sort(names)
	fmt.Println(names)

	// Descending: sort ascending, then flip
	slices.Reverse(nums)
	fmt.Println(nums)
}

Prints [1 2 5 7 9], [apple banana cherry], then [9 7 5 2 1]. Note what it does not return: the slice is reordered in place and slices.Sort returns nothing, so x := slices.Sort(s) is a compile error. Strings sort by byte value, which means every uppercase letter sorts before every lowercase one — "Zebra" lands before "apple". Companion helpers: slices.IsSorted checks without touching the data, and slices.BinarySearch gives you O(log n) lookups once the slice is sorted.

2Structs and custom orders: slices.SortFunc

Real data is rarely a bare []int. slices.SortFunc(s, cmp) takes a three-way comparison — negative if a comes first, zero if they tie, positive if b comes first — and cmp.Compare from the cmp package writes it for you on any ordered field. Reversing the order is then just swapping the two arguments.

package main

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

type Employee struct {
	Name   string
	Salary int
}

func main() {
	staff := []Employee{
		{"carol", 95000},
		{"alice", 120000},
		{"bob", 78000},
	}

	// Ascending by salary -- cmp.Compare returns -1, 0 or +1
	slices.SortFunc(staff, func(a, b Employee) int {
		return cmp.Compare(a.Salary, b.Salary)
	})
	fmt.Println(staff)

	// Descending: swap a and b in the comparison
	slices.SortFunc(staff, func(a, b Employee) int {
		return cmp.Compare(b.Salary, a.Salary)
	})
	fmt.Println(staff)
}

Prints [{bob 78000} {carol 95000} {alice 120000}] then the same three in reverse. Prefer cmp.Compare to hand-written if a < b { return -1 } chains: it handles NaN and the equality case correctly and it is one line. Sorting case-insensitively is the same shape — cmp.Compare(strings.ToLower(a), strings.ToLower(b)).

3sort.Slice (any Go version)

Before generics, sorting anything but []int/[]string/[]float64 meant sort.Slice, whose closure takes indices rather than values and returns true when element i should sort before element j. It still works, it is what most pre-1.21 code uses, and it is the only option if you must support old toolchains.

package main

import (
	"fmt"
	"sort"
)

func main() {
	words := []string{"kiwi", "fig", "banana", "apple"}

	// Any Go version: a "less" closure that indexes the slice itself
	sort.Slice(words, func(i, j int) bool {
		return len(words[i]) < len(words[j])
	})
	fmt.Println(words)

	// The pre-generics typed helpers still compile
	nums := []int{5, 2, 9, 1}
	sort.Ints(nums)
	fmt.Println(nums)
}

Prints [fig kiwi apple banana] (shortest word first) then [1 2 5 9]. Two costs make slices.SortFunc the better default today: the closure captures the slice variable, so it silently breaks if you reassign words mid-sort, and sort.Slice reaches the elements through reflection, which is why the generic version benchmarks faster. sort.Ints, sort.Strings, and sort.Float64s are formally deprecated as of Go 1.22 in favour of slices.Sort.

4Stable sorts and multi-key ordering

slices.Sort and slices.SortFunc are not stable: elements that compare equal can come out in any order, and the order may change between Go releases. That matters the moment you sort by two keys. Either sort twice with slices.SortStableFunc — least significant key first — or compare both keys in one pass with cmp.Or, which returns its first non-zero argument.

package main

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

type Player struct {
	Name  string
	Score int
}

func main() {
	players := []Player{
		{"dana", 90},
		{"alice", 90},
		{"carol", 70},
		{"bob", 70},
	}

	// Pass 1: the tie-breaker key.
	slices.SortFunc(players, func(a, b Player) int {
		return cmp.Compare(a.Name, b.Name)
	})
	// Pass 2: the primary key, stably -- names stay in order inside each score.
	slices.SortStableFunc(players, func(a, b Player) int {
		return cmp.Compare(b.Score, a.Score)
	})
	fmt.Println(players)

	// Or one pass with cmp.Or (Go 1.22+): the first non-zero comparison wins.
	slices.SortFunc(players, func(a, b Player) int {
		return cmp.Or(cmp.Compare(b.Score, a.Score), cmp.Compare(a.Name, b.Name))
	})
	fmt.Println(players)
}

Both lines print [{alice 90} {dana 90} {bob 70} {carol 70}] — highest score first, alphabetical within a score. The one-pass cmp.Or version is the one to reach for: it needs no stability guarantee, it states the whole ordering in one place, and it is a single sort instead of two. Reserve the stable two-pass form for when the existing order is meaningful and you cannot express it as a comparison — data already ordered by arrival time, say.

5Which should you use?

6Sorting mutates — clone when it matters

Every sort in Go reorders the slice you hand it; none returns a new one. Pass a slice to a function that sorts it and the caller's data is sorted too — slices are headers over a shared backing array, so the reordering is visible everywhere that array is reachable. slices.Clone is the fix, and the same aliasing explains why sorting a sub-slice quietly rearranges its parent.

package main

import (
	"fmt"
	"slices"
)

func main() {
	original := []int{5, 2, 9, 1}

	// Sort a copy when the caller still needs the original order
	sorted := slices.Clone(original)
	slices.Sort(sorted)
	fmt.Println(original)
	fmt.Println(sorted)

	// Sub-slices share the backing array -- sorting one reorders the parent
	part := original[:3]
	slices.Sort(part)
	fmt.Println(original)
}

Prints [5 2 9 1], [1 2 5 9], then [2 5 9 1] — the clone left original alone, but sorting the three-element part rewrote the first three elements of original in place. That last line is the whole hazard in one statement. If a function takes a slice and sorts it, document that it does, or clone inside it.

7Sorted map iteration

Go deliberately randomises map iteration order, so ranging a map gives different output on every run — the reason so many Go tests flake on their first day. Maps cannot be sorted; the idiom is to collect the keys into a slice, sort that, and range the keys.

package main

import (
	"fmt"
	"maps"
	"slices"
)

func main() {
	stars := map[string]int{"go": 124, "rust": 98, "zig": 35}

	keys := make([]string, 0, len(stars))
	for k := range stars {
		keys = append(keys, k)
	}
	slices.Sort(keys)

	for _, k := range keys {
		fmt.Println(k, stars[k])
	}

	// Go 1.23+ one-liner over the map's key iterator
	fmt.Println(slices.Sorted(maps.Keys(stars)))
}

Prints go 124, rust 98, zig 35, then [go rust zig] — in that order, every single run. Pre-allocating with make([]string, 0, len(stars)) avoids regrowing the slice as you append. On Go 1.23+, slices.Sorted(maps.Keys(m)) collapses the whole collect-and-sort dance into one expression. To order by value instead, sort the key slice with slices.SortFunc comparing m[a] against m[b]. Reading values back out is the comma-ok lookup.