// HACKER NEWS — CYBERSECURITY
How Swiss tables work in Go built-in map
We have already written about Go maps and their old runtime implementation in Go Maps Explained: How Key-Value Pairs Are Actually Stored. Go 1.24 replaced that implementation with a design based on Swiss Tables, so it is time for an update.
You do not need to go back and read the old article. We will review how maps behave and the concepts needed here before moving into the new runtime internals.
The Go blog also has an excellent article, Faster Go maps with Swiss Tables. It goes deeper and assumes a little more background knowledge. We take a different approach. We will discuss the same implementation more gradually and in a visual way, so you can relax your brain a little and still understand what Go is doing.
make initializes the map. map[string]int is the language-level type, which tells us that the map uses strings as keys and integers as values. Underneath that type, the runtime representation of m is a pointer to internal/runtime/maps.Map.
We can easily inspect this with println, which prints that pointer:
Copying m to another map variable copies this pointer, so both variables refer to the same runtime Map and the same entries.
The 2 fields at the top describe the map itself, not the storage for its entries.
used counts how many entries are currently stored. Since Go knows exactly where to find the number of entries, when you write len(m), Go replaces this call with an access to the first field of Map and converts it to an int. That is why len(m) is O(1) instead of scanning the entire map.
seed is an interesting field because it causes different maps to distribute the same keys differently. Go initializes this field with a random number for every map.
The array above is only a simplified representation used for this explanation. The actual data structure is more complicated.