Fixed-Size Arrays

A latency probe runs at a checkpoint and captures exactly five round-trip samples before it reports anything. You want the compiler to enforce that contract, not a comment above the function. The array type does it for you:

func summarize(samples [5]time.Duration) string {
	var total time.Duration
	for _, s := range samples {
		total += s
	}
	return fmt.Sprintf("avg %v across %d samples", total/len(samples), len(samples))
}

A caller holding four samples cannot compile a call to summarize. Passing six fails too, because [6]time.Duration is not a slightly larger version of [5]time.Duration — it is a different type, exactly as int32 and int64 are different types. Length lives in the type name, and that one fact drives everything else about arrays:

var a [3]int
var b [4]int
a = b // compile error: cannot use b (type [4]int) as [3]int value

Because the compiler knows the size at compile time, an array value is complete on its own. var samples [5]time.Duration allocates five durations, all zeroed, immediately. There is no make, no initialization step, and no nil to check later. The zero value of an array is the zero value of its element type, repeated length times — an array of strings is five empty strings, an array of structs is five zeroed structs.

Arrays also inherit comparability from their elements. Two arrays of the same length compare with == element by element whenever the element type itself is comparable:

name := [2]string{"li", "chen"}
alias := [2]string{"li", "chen"}
fmt.Println(name == alias) // true

Comparability is a capability slices will never have, and it unlocks using fixed byte blocks as map keys later on (Maps: Insert, Lookup, and Delete).

The cost of the compiler knowing the size is that every operation on an array treats it as one indivisible unit of memory. Copying a variable copies all N elements. Passing one into a function passes all N elements. There is no shared header, no window, no aliasing — which makes arrays easy to reason about and expensive to move once N grows. That trade decides where arrays belong in real code, which is the next question.

A small grading service keeps one row of four quiz scores per student. Rows get archived before scores are adjusted, so you reach for a plain copy:

func main() {
	scores := [4]int{70, 85, 90, 60}
	archive := scores   // full copy: four ints duplicated
	scores[1] = 95      // archive[1] is still 85

	adjust(scores)
	fmt.Println(scores[0]) // still 70 — adjust edited its own copy
}

func adjust(row [4]int) {
	row[0] = 100 // writes go into the parameter's private copy
}

Two different places behaved identically: assignment and parameter passing both duplicated every element. This is value semantics, and for arrays it is literal — the language copies the bytes. The function cannot corrupt the caller's row no matter what it does to the parameter, which is exactly the isolation the archive needed.

The same rule applies inside for range, and this is where it surprises people:

scores := [4]int{70, 85, 90, 60}

for _, score := range scores {
	score += 5 // compiles, does nothing visible
}
for i := range scores {
	scores[i] += 5 // correct: write through the index
}

score is a fresh copy of each element per iteration. Modifying it edits the copy, throws it away, and moves on. The second loop receives only the index and writes back into the real array. Whenever a loop is supposed to transform array contents, index-based mutation is the only form that works.

Predicting copies becomes a practical skill once you compare containers. An array copies its elements. A struct containing an array copies the array inside it. A slice, as you will see in Slice Basics and the Slice Header, copies only a three-word header while the elements stay shared. Mixed code that passes both around behaves very differently depending on which type it holds, and interviewers like exactly that question: "what gets copied here?" Start the habit now by asking it of every assignment you write.

Production Go rarely declares []int-shaped variables as arrays, yet arrays appear at every boundary where the fixed size is the point. Hash digests are the classic case — sha256.Sum256 returns [32]byte, not a slice:

func dedupeFiles(paths []string) ([]string, error) {
	seen := map[[32]byte]bool{} // comparable key: arrays qualify, slices never do
	var unique []string
	for _, p := range paths {
		data, err := os.ReadFile(p)
		if err != nil {
			return nil, err
		}
		sum := sha256.Sum256(data) // [32]byte value, copied on assignment
		if !seen[sum] {
			seen[sum] = true
			unique = append(unique, p)
		}
	}
	return unique, nil
}

The digest must be a value you can hash, compare, and store as a map key — all things a 32-byte array does natively. The same shape covers MAC tags, IPv6 addresses ([16]byte), and fixed grids. A tic-tac-toe board writes naturally as a nested array, with element types elided inside the literal:

var board [3][3]byte
board[0][2] = 'X'

start := [3][3]byte{
	{'X', 'O', 0},
	{0, 'X', 0},
	{0, 0, 'O'},
}
fmt.Println(len(board), len(board[0])) // 3 3

Notice there is no [][]byte here: a slice of slices would be two separately allocated regions with two headers. The nested array is one contiguous 9-byte block with dimensions baked into the type, so bounds checks need no extra indirection.

Where arrays lose: anything whose length is chosen at runtime, grows over time, or crosses many function boundaries. Moving a 4 KB array through five call layers means five 4 KB copies, and the compiler's escape analysis may even push it to the heap (Heap Escape Analysis). The usual pattern is to own a fixed array internally and hand slices outward:

type Ring struct {
	buf  [64]int // storage stays fixed and private
	fill int
}

func (r *Ring) Values() []int { return r.buf[:r.fill] } // array exposed as a slice

Calling r.buf[:r.fill] builds a slice header over the existing storage without copying anything (Slice Basics and the Slice Header). That is the relationship to remember: arrays are the concrete, sized blocks; slices are the variable-length views that flow through Go APIs. Know the array's strengths — comparability, fixed layout, copy isolation — and let slices carry the data everywhere else.