Slice and array relationship in Go - Deep Dive

Overview - Slice and array relationship

What is it?

In Go, an array is a fixed-size collection of elements of the same type. A slice is a flexible, dynamic view into an array, allowing you to work with parts or all of the array without copying data. Slices provide a way to handle sequences of elements more easily than arrays because their size can change during runtime.

Why it matters

Slices exist to solve the problem of fixed-size arrays, which are rigid and hard to work with when you don't know the exact number of elements in advance. Without slices, programmers would need to create new arrays and copy data every time they want to resize, making code inefficient and complex. Slices make Go programs more flexible and memory-efficient by sharing the underlying array data.

Where it fits

Before learning slices, you should understand basic Go arrays and how memory works in Go. After mastering slices, you can learn about Go's built-in functions for slices, such as append and copy, and then move on to more advanced topics like concurrency-safe data structures or custom collection types.

Mental Model

Core Idea

A slice is a window that looks into an underlying array, letting you see and change a part of it without copying the data.

Think of it like...

Imagine an array as a long bookshelf filled with books. A slice is like taking a bookmark that points to a specific section of that shelf. You can read or rearrange books in that section without moving the entire shelf.

Array: [A][B][C][D][E][F][G][H]
Slice1:       ┌─────────────┐
              │[C][D][E][F]│
              └─────────────┘
Slice2:             ┌─────┐
                    │[E][F][G]│
                    └─────┘

Build-Up - 7 Steps

1

Foundation

Understanding Go arrays basics

Concept: Learn what arrays are in Go and how they store fixed-size collections.

An array in Go holds a fixed number of elements of the same type. For example: var arr [5]int This creates an array of 5 integers. You cannot change its size after creation. You access elements by index, starting at 0. arr[0] = 10 fmt.Println(arr[0]) // prints 10

Result

You can store and access fixed-size collections, but cannot resize the array.

Understanding arrays is essential because slices depend on arrays as their underlying storage.

2

Foundation

Introducing slices as flexible views

Concept: Slices are references to arrays that allow flexible, resizable views of the data.

A slice points to a segment of an array and has three parts: pointer to the array, length, and capacity. Example: arr := [5]int{1, 2, 3, 4, 5} slice := arr[1:4] // slice contains elements at index 1,2,3 fmt.Println(slice) // prints [2 3 4]

Result

You get a flexible view into part of the array without copying data.

Slices let you work with parts of arrays dynamically, avoiding the rigidity of fixed-size arrays.

3

Intermediate

How slices share underlying arrays

🤔Before reading on: do you think modifying a slice changes the original array or creates a copy? Commit to your answer.

Concept: Slices share the same underlying array, so changes through a slice affect the array and other slices referencing it.

When you create a slice from an array, the slice points to the same memory. For example: arr := [3]int{10, 20, 30} slice := arr[0:2] slice[0] = 100 fmt.Println(arr) // prints [100 20 30] fmt.Println(slice) // prints [100 20]

Result

Changing the slice changes the original array because they share memory.

Knowing slices share memory helps avoid bugs where changing one part unexpectedly affects others.

4

Intermediate

Slice length and capacity explained

🤔Before reading on: do you think slice length and capacity are always the same? Commit to your answer.

Concept: Slices have length (number of elements visible) and capacity (max elements before resizing) which control how they grow.

Length is how many elements the slice currently holds. Capacity is how many elements it can hold before needing a new array. Example: arr := [5]int{1,2,3,4,5} slice := arr[1:3] // length=2, capacity=4 fmt.Println(len(slice)) // 2 fmt.Println(cap(slice)) // 4

Result

You understand how slices can grow up to their capacity without reallocating.

Distinguishing length and capacity is key to efficient slice use and avoiding unexpected reallocations.

5

Intermediate

Creating slices without arrays

Concept: You can create slices directly without declaring arrays using make, which allocates an underlying array automatically.

Using make, you create a slice with specified length and capacity: slice := make([]int, 3, 5) // length 3, capacity 5 fmt.Println(slice) // [0 0 0] This slice has an underlying array of size 5, but only 3 elements are visible.

Result

You can create flexible slices without manually creating arrays first.

make abstracts away arrays, letting you focus on slice behavior and dynamic resizing.

6

Advanced

Appending and slice reallocation

🤔Before reading on: when appending to a slice beyond capacity, does Go modify the original array or create a new one? Commit to your answer.

Concept: Appending beyond capacity causes Go to allocate a new, larger array and copy data, breaking the link to the original array.

Example: arr := [3]int{1,2,3} slice := arr[:2] // length 2, capacity 3 slice = append(slice, 4) // capacity exceeded, new array allocated slice[0] = 100 fmt.Println(arr) // prints [1 2 3], unchanged fmt.Println(slice) // prints [100 2 4]

Result

Appending beyond capacity creates a new array, so changes to the slice no longer affect the original array.

Understanding when slices share or separate memory prevents bugs with unexpected data changes.

7

Expert

Slice internals and memory model

🤔Before reading on: do you think slices store the entire array or just a pointer and metadata? Commit to your answer.

Concept: Slices are small structs holding a pointer to the array, length, and capacity, not the array data itself.

Internally, a slice is: struct { ptr *ElementType len int cap int } This means slices are lightweight and copying a slice copies only this struct, not the underlying array. This design allows efficient passing of slices without copying large data.

Result

Slices are efficient references, not heavy copies, enabling performant code.

Knowing slice internals explains why slices are cheap to pass and how they behave in memory.

Under the Hood

A slice in Go is a descriptor containing a pointer to an underlying array, a length, and a capacity. When you create or slice a slice, Go does not copy the array data but adjusts the pointer and length/capacity fields. When appending exceeds capacity, Go allocates a new array, copies existing data, and updates the slice pointer. This mechanism balances flexibility and performance by avoiding unnecessary copying.

Why designed this way?

Go was designed for simplicity and efficiency. Arrays are fixed-size and cumbersome for dynamic data. Slices provide a lightweight abstraction over arrays, enabling dynamic resizing without losing performance. The design avoids copying data unless necessary, which is critical for system programming and large data handling. Alternatives like linked lists or dynamic arrays with frequent copying were rejected for complexity or inefficiency.

┌─────────────┐
│   Slice     │
│─────────────│
│ ptr ────────┼─────┐
│ len         │     │
│ cap         │     │
└─────────────┘     │
                    ▼
             ┌─────────────────┐
             │   Array         │
             │ [0][1][2][3][4] │
             └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does changing a slice always change the original array? Commit yes or no.

Common Belief: Changing a slice never affects the original array because slices are copies.

Reality: Slices share the underlying array, so modifying a slice changes the array and all slices referencing it, unless a new array was allocated after append.

Why it matters: Believing slices are copies leads to bugs where data changes unexpectedly propagate or don't propagate as expected.

Quick: Is the capacity of a slice always equal to its length? Commit yes or no.

Common Belief: Slice length and capacity are always the same.

Reality: Length is how many elements are accessible; capacity is how many elements can be stored before resizing. Capacity is often larger than length.

Why it matters: Misunderstanding capacity causes inefficient code or unexpected reallocations during append.

Quick: Does appending to a slice always modify the original array? Commit yes or no.

Common Belief: Appending to a slice always changes the original array's data.

Reality: Appending beyond capacity creates a new array, so changes after that do not affect the original array.

Why it matters: Assuming append always modifies the original array can cause subtle bugs in shared data scenarios.

Quick: Are slices large data structures that copy arrays when passed to functions? Commit yes or no.

Common Belief: Slices copy the entire underlying array when passed around.

Reality: Slices are small structs with pointers; passing them copies only the descriptor, not the array data.

Why it matters: Thinking slices are heavy leads to unnecessary copying or inefficient code design.

Expert Zone

1

Appending to a slice may cause a new array allocation, but Go's runtime often doubles capacity to reduce reallocations, balancing memory and speed.

2

Slicing a slice creates a new slice header but points to the same underlying array, so multiple slices can share overlapping data regions.

3

When passing slices to functions, modifying the slice's elements affects the caller's data, but re-slicing or appending may not if capacity is exceeded.

When NOT to use

Slices are not suitable when you need immutable collections or thread-safe concurrent access without synchronization. In such cases, use arrays for fixed data or specialized concurrent-safe data structures like channels or sync.Mutex-protected slices.

Production Patterns

In production Go code, slices are used extensively for dynamic data handling, often combined with append for growth. Developers carefully manage slice capacity to optimize performance and avoid unnecessary allocations. Slices are also passed to functions to share data efficiently without copying large arrays.

Connections

Pointers in Go

Slices internally use pointers to reference arrays.

Understanding pointers clarifies how slices reference data without copying, explaining their efficiency and behavior.

Dynamic arrays in other languages

Slices are Go's version of dynamic arrays or lists found in languages like Python or JavaScript.

Knowing how other languages handle dynamic collections helps appreciate Go's slice design and its balance of performance and flexibility.

Windowing in signal processing

Slices act like windows selecting parts of a larger data set, similar to how signal processing uses windows to analyze segments.

This connection shows how slices provide focused views on data, enabling efficient partial processing without copying.

Common Pitfalls

#1 Modifying a slice after append without checking capacity causes unexpected data changes.

Wrong approach:

arr := [3]int{1,2,3}
slice := arr[:2]
slice = append(slice, 4)
slice[0] = 100
fmt.Println(arr) // expects arr to change but it doesn't

Correct approach:

arr := [3]int{1,2,3}
slice := arr[:2]
slice[0] = 100
slice = append(slice, 4)
fmt.Println(arr) // arr changes before append, append may create new array

Root cause:

Not realizing append beyond capacity creates a new array, so changes after append don't affect original array.

#2 Assuming slice length equals capacity leads to inefficient appends.

Wrong approach:

slice := make([]int, 3)
for i := 0; i < 10; i++ {
slice = append(slice, i)
}

Correct approach:

slice := make([]int, 3, 10)
for i := 0; i < 10; i++ {
slice = append(slice, i)
}

Root cause:

Not setting capacity upfront causes multiple reallocations and copies during append.

#3 Passing slices to functions and modifying length expecting original slice length to change.

Wrong approach:

func modify(s []int) {
s = s[:1]
}

slice := []int{1,2,3}
modify(slice)
fmt.Println(slice) // expects [1], but prints [1 2 3]

Correct approach:

func modify(s *[]int) {
*s = (*s)[:1]
}

slice := []int{1,2,3}
modify(&slice)
fmt.Println(slice) // prints [1]

Root cause:

Slices are passed by value; changing length inside function doesn't affect caller unless pointer to slice is used.

Key Takeaways

Slices in Go are flexible, dynamic views into fixed-size arrays, allowing efficient data manipulation without copying.

A slice contains a pointer to an array, a length, and a capacity, which control how much data it shows and can grow.

Modifying a slice changes the underlying array unless the slice grows beyond capacity, causing a new array allocation.

Understanding slice internals and behavior prevents common bugs related to shared data and unexpected reallocations.

Slices are a core Go feature that balance performance and flexibility, making them essential for effective Go programming.