Chapter 5 Data Structures on Go: Under the Hood

5.1 Arrays and Slices

Mon, 01 Jan 0001 00:00:00 +0000

5.1 Arrays and Slices

Arrays and slices are the two most basic sequence types in Go. They look similar, yet their memory models differ, and grasping this one point explains in a single stroke all the “surprises” of append and the traps of slice aliasing. Both share a single theme: a small header describing a stretch of contiguous backing memory. The differences lie entirely in what the header holds and who owns that memory. This section first lays out the layout clearly, then starts from the classic abstraction of the “dynamic array” to see how Go’s append achieves amortized $O(1)$ , and finally lands on aliasing and cross-language comparison, the corners we run into day to day. Strings, though they share the same origin as slices, are immutable and form a category of their own; we leave them to 5.2 for dedicated discussion.

5.2 Strings and Zero-Copy Conversion

Mon, 01 Jan 0001 00:00:00 +0000

5.2 Strings and Zero-Copy Conversion

Strings share their origin with slices: in the runtime both are “a header plus memory living elsewhere” (for the layout, see 5.1.1). But a string is read-only and immutable, which makes it its own category. Immutability buys us sharing and copy-free use, and it brings one direct cost: converting between string and []byte copies the bytes by default. This section opens up that copy, looks at the cases where the compiler can elide it, then turns to the manual zero-copy tools Go 1.20 provides and the safety contract that comes with them.

5.3 Hash Tables: Principles and Security

Mon, 01 Jan 0001 00:00:00 +0000

5.3 Hash Tables: Principles and Security

Go’s map underwent a rare, complete rewrite in 2024 alongside Go 1.24, moving from the classic bucketed hash table it had used for fourteen years to an implementation based on Swiss Tables. This section first clarifies the general principles of hash tables and the attack-and-defense around them, leaving the full story of the rewrite to 5.4.

map is one of only two generic containers Go provides (the other being slice). It is implemented by the runtime with the compiler assisting in layout, and at its core it is a hash table. When the reader writes m[k], the compiler translates it into calls to the runtime.mapaccess and runtime.mapassign family of functions; the real storage, lookup, and growth all happen inside the internal/runtime/maps package. This section first lays out the general principles of hash tables and the attack-and-defense around them, to ground the next section where we drop down to Go’s own two generations of implementation (the classic bucketed design from 1.0 through 1.23, and the Swiss Table design from 1.24 onward). Only by understanding the trade-offs here can we see why the latter was worth a rewrite that cut to the bone.

5.4 Swiss Table and the Go 1.24 Implementation

Mon, 01 Jan 0001 00:00:00 +0000

5.4 Swiss Table and the Go 1.24 Implementation

5.3 laid out the general principles of hash tables and the attack-and-defense around them: the two routes for handling collisions, and the defense against hash flooding. This section comes down to Go’s own two generations of implementation. We first open up Swiss Table, a modern open-addressing design, then look at how Go 1.24 brought it to ground and what it replaced in the process, then derive from the implementation two language rules that follow from it, and finally place Go within the larger picture of the various hash tables out there.