Slices, Maps & Strings

Create one with make(map[K]V) or a literal map[K]V{...}. Store with m[k] = v, read with m[k]. A plain read never fails: a missing key returns the value type's zero value, so you cannot tell "absent" from "present but zero". The comma-ok form v, ok := m[k] settles that — ok is false only when the key is absent. Note a nil map reads fine but panics on write, so make it first.

A slice is a lightweight view over a backing array — a header of pointer, length, and capacity. append adds elements at the end; while capacity is free it writes in place, but once length would exceed capacity it allocates a new, larger backing array, copies the old elements over, and returns a slice pointing at it. Because that returned header may differ, you must reassign s = append(s, x).

An array has a fixed length that is part of its type; it is a value, so assigning or passing it copies every element. A slice is a small header referencing a backing array — passing it copies only the header, so both copies share the elements.

A nil slice (var a []int) has no backing array and a == nil is true; an empty slice ([]int{}) is non-nil with len 0. Both have len 0, accept append, and range cleanly. Prefer nil for "no results" — but a nil slice marshals to JSON null while an empty one marshals to [].

A slice header is three words: a pointer to the first element of the backing array, the length len (the number of accessible elements), and the capacity cap (elements from the pointer to the end of the backing array). It holds no elements itself.

s[i] returns one byte (a uint8) — the i-th raw UTF-8 byte, not a character. len(s) counts bytes too, not runes. An ASCII character is one byte, but any multi-byte UTF-8 character (say é or ы) spans several bytes, so len over-counts such text and s[i] can land mid-character. To work in characters, range over the string (which decodes runes) or convert with []rune(s) and index that.

The read m["x"] is fine and returns the zero value 0 — reading a nil map never panics. The write m["x"] = 1 panics with assignment to entry in nil map. You must initialize the map first with make(map[string]int) or a literal before writing to it.

It prints 4 4, then x: [a b z d] and y: [a b z]. y := x[:2] has len 2 but inherits cap 4 to the end of x's backing array, so append(y, "z") has spare room and writes into the shared x[2], overwriting c instead of allocating.

The order is randomized — Go deliberately starts each range over a map at a random bucket, so iteration order is not stable across runs or even across loops in the same run. This is by design, to stop code from accidentally depending on map internals. If you need a stable order, collect the keys into a slice and sort it.

It prints x: [a b c d], y: [a b], z: [b c d], d: [b c], e: [a b c d]. The form x[low:high] yields elements from index low up to high-1, so its length is high-low; an omitted bound defaults to 0 or len(x).

It does not compile. A Go string is an immutable, read-only sequence of bytes, so s[0] = ... is illegal. (s[0] reads a byte, not a string, so "R" is a type mismatch too.) To change a byte, convert: b := []byte(s); b[0] = 'R'; s = string(b).

A string value is a two-word header — an 8-byte pointer to immutable UTF-8 bytes plus an 8-byte length — so it is 16 bytes on a 64-bit platform regardless of text length. The bytes live separately, so a struct with one string field is also 16 bytes.

A nil slice and a nil map both read safely — len is 0, ranging yields nothing, and a nil map read returns the value type's zero. The split is on writing. You may append to a nil slice freely: append allocates a fresh backing array, so var s []int; s = append(s, 1) just works and needs no initialization. A nil map, though, panics the moment you assign m[k] = v; you must make(map[K]V) (or use a literal) before any write.

All three print their original values — [1 2 3 4 5], [2 3 4 5], [3 4]. slice1 has cap 4 and slice2 cap 3, so appending two elements overflows both. Each append allocates a fresh backing array and reassigns only the local copy of the header, so the caller's headers and arr never see it.

Choose an array when the length is a fixed compile-time constant and you want value semantics — arrays are comparable with ==, usable as map keys, and copy as a whole, avoiding a separate backing allocation. Choose a slice (the default) whenever the length varies or grows, or when you want to pass a view without copying every element.

A buffer overflow is writing past the end of an array or buffer, corrupting adjacent memory — possible in C because there are no bounds checks. In ordinary Go it cannot happen: slice and array accesses are bounds-checked, and an out-of-range index panics instead of overwriting memory. You can only bypass this with the unsafe package.

A Go map is an hmap struct pointing at an array of buckets. Each bucket holds up to 8 key/value slots plus a link to overflow buckets. A key's hash selects the bucket; its top bits speed slot scanning. When buckets fill up, the map grows and rehashes into a larger array.

It prints [1 99 3] [1 99]. a[:1] has len 1 but cap 3, so append has spare capacity and writes 99 into the same backing array at index 1, overwriting a[1]. Both slices view that array. Force a copy with the full-slice expression a[:1:1] so append reallocates.

Make an independent copy with copy(dst, src) into a freshly allocated slice, or cap capacity with the three-index expression s[low:high:max] so the next append must reallocate instead of overwriting shared elements. Return copies, not sub-slices, from APIs so callers cannot mutate your backing array.

When append needs more room than cap, the runtime allocates a new, larger backing array, copies the existing elements into it, and returns a new header pointing there. Growth roughly doubles capacity for small slices and uses a smaller factor (about 1.25x) for large ones.

Slices share a backing array, so three pitfalls follow. Writing through one slice mutates others where ranges overlap. append may or may not touch the original, depending on spare capacity. And a small sub-slice keeps the whole large array alive, blocking GC. Mitigate with copy or s[low:high:max].

It prints a b c d. range evaluates its operand once at the start and iterates over a copy of the slice header (pointer, len, cap). Reassigning lst to a brand-new slice only rebinds the variable — the loop keeps iterating the original backing array. If instead you mutated an element of the original backing array, e.g. lst[3] = "z", the loop would see it and print a b c z.

It prints x: [x y z d], y: [x y], z: [y z d]. Both y := x[:2] and z := x[1:] reslice x, so they share its backing array. x[1]="y", y[0] writes x[0]="x", and z[1] writes x[2]="z", all visible through every overlapping range.

A lookup hashes the key, selects a bucket, then compares the hash's top byte (tophash) against each of the bucket's 8 slots — a 1-byte filter that skips full key comparison on a miss. Only a tophash match triggers a full key compare. If all 8 slots miss, it follows the bucket's overflow pointer and repeats down the chain.

A map element is not addressable because growth relocates entries: when the map exceeds its load factor it allocates a larger bucket array and evacuates entries incrementally — each bucket is rehashed and copied during later writes. A stored &m[k] would dangle after a move, so it does not compile.