In Go, how does `[3][4]int` differ from `[][]int` for a two-dimensional grid?

## Three ways to spell a two-dimensional grid Go has no dedicated matrix type, so a grid is built out of the two composite types the language does have. The choice between them is a memory-layout choice. ### `[3][4]int` — an array of arrays This is a single value: three elements, each of which is a `[4]int`. Both dimensions come from the type, so the whole thing is 12 ints laid out contiguously in memory, in row-major order. It needs no `make`, it is zeroed on declaration, and a local one can live in the function's frame with no allocation at all. Because it is one value, all the array rules apply to the whole grid: assigning it copies all 12 ints, passing it to a function copies all 12, and its shape can never change. `len(grid)` is 3 and `len(grid[0])` is 4, both constants. ```go var grid [3][4]int grid[1][2] = 7 other := grid // copies all twelve ints ``` ### `[][]int` — a slice of slices Here the outer value is a slice whose element type is `[]int`. This is the flexible form, and the thing that surprises newcomers is that `make` only builds the outer level: ```go rows := make([][]int, 3) // three rows, each a nil []int rows[1][2] = 7 // panics: index out of range on a nil row ``` Each row has to be created in its own right: ```go rows := make([][]int, 3) for i := range rows { rows[i] = make([]int, 4) } ``` That is four allocations in total, and the four rows' elements are four separate runs of memory that happen to be pointed at by one outer slice. Consequences: - **Rows are independent.** They may have different lengths — a jagged table — and a row can be replaced or grown without touching the others. - **There is an extra indirection.** Reading `rows[r][c]` follows the outer slice to a row value and then that row to its elements, whereas `grid[r][c]` is one address computation. - **Locality is worse.** Separately allocated rows need not be adjacent, so a scan over a large grid touches scattered memory. - **Copying the outer slice shares the rows.** Assigning `other := rows` gives two outer slices over the same row values, so writes through either are visible to both, all the way down. ### The flat slice When the dimensions are only known at run time but you still want one contiguous block, the usual answer is to flatten: ```go cols := 4 cells := make([]int, 3*cols) cells[1*cols+2] = 7 ``` One allocation, contiguous elements, run-time size — at the price of doing the index arithmetic yourself and losing the `grid[r][c]` notation. A variation keeps both: allocate one flat backing slice, then build a `[][]int` whose rows are sub-slices of it, giving two-index syntax over contiguous memory. ### Choosing Fixed, small, shape known at compile time — an array of arrays, and let it be copied. Shape known only at run time, or rows genuinely of different lengths — a slice of slices. Shape known only at run time but performance-sensitive and rectangular — a flat slice, possibly with row sub-slices layered over it. The same reasoning applies to the fixed-size buffers a device-facing daemon holds: a ring of eight 32-byte frames is naturally `[8][32]byte`, one contiguous 256-byte value with no allocation and no per-row pointer, and it can be handed around as a single value.