Arrays vs Slices in Golang: A Detailed Visual Guide

Why Array is Copy By Default?

When you assign or pass arrays in Go, they create copies by default. This ensures data isolation and prevents unexpected mutations.

func modifyArrayCopy(arr [5]int) {
    arr[0] = 999    // Modifies the copy, not original
}
 
func modifyArray(arr *[5]int){
    arr[0] = 999  // Modifies the original, since reference is passed
}
 
func main() {
    numbers := [5]int{1, 2, 3, 4, 5}
 
    modifyArrayCopy(numbers)
    fmt.Println(numbers[0])  // prints 1, not 999
 
    modifyArray(&numbers)
    fmt.Println(numbers[0])  // prints 999
}

Slices under the hood

The magic lies in how it maintains this flexibility while keeping operations fast.

Every slice in Go consists of three critical components:

type slice struct {
    array unsafe.Pointer // Points to the actual data
    len   int           // Current number of elements
    cap   int           // Total available space
}

What’s unsafe.Pointer??

The unsafe.Pointer is Go’s way of handling raw memory addresses without type safety constraints. It’s “unsafe” because it bypasses Go’s type system, allowing direct memory manipulation.

Think of it as Go’s equivalent to C’s void pointer.

What’s that array?

When you create a slice, Go allocates a contiguous block of memory in the heap (unlike arrays) called backing array. Now the array in slice struct points to the start of that memory block.

The array field uses unsafe.Pointer because:

1. It needs to point to raw memory without type information
2. It allows Go to implement slices for any type T without generating separate code for each type.

The dynamic mechanism of slice

let’s try developing intuition for the actual algorithm under the hood.

If we go by intuition we can do two things:

1. We could set aside space so large and can use it as and when required pros: Handles growing needs till a certain point cons: Memory wastage, practically might hit limit

2. We could set a random size initially and as the elements are appended we can reallocate the memory on each append pros: Handles the previous case, can grow as per the need cons: reallocation is expensive and on every append it’s going to get worst

We cannot avoid the reallocation as when the capacity hits one needs to grow. We can minimize the reallocation so that the subsequent inserts/appends cost is constant (O(1)). This is called amortized cost.

How can we go about it?

till Go version v1.17 following formula was being used:

// Old growth pattern
capacity = oldCapacity * 2  // Simple doubling

from Go version v1.18:

// New growth pattern
if capacity < 256 {
    capacity = capacity * 2
} else {
    capacity = capacity + capacity/4  // 25% growth
}

since doubling a large slice is waste of memory so as the slice size increases the growth factor is decreased.

Let’s get a better understanding from usage perspective

numbers := make([]int, 3, 5) // length=3 capacity
 
// Memory Layout after creation:
Slice Header:
{
    array: 0xc0000b2000    // Example memory address
    len:   3
    cap:   5
}
 
Backing Array at 0xc0000b2000:
[0|0|0|unused|unused]

let’s add some elements to our slice

numbers = append(numbers, 10)

Since we have capacity (5) > length (3), Go:

Uses existing backing array Places 10 at index 3 Increases length by 1

// Memory Layout after first append:
Slice Header:
{
    array: 0xc0000b2000    // Same memory address!
    len:   4               // Increased
    cap:   5               // Same
}
 
Backing Array at 0xc0000b2000:
[0|0|0|10|unused]

Let’s hit the limit

numbers = append(numbers, 20)  // Uses last slot
numbers = append(numbers, 30)  // Needs to grow!

When the capacity is reached (cap = 5, len = 5):

Go creates a new, larger backing array. Copies elements from the old array. Appends the new element (30). Updates the slice header’s array pointer, len, and cap.

// Memory Layout after reallocation:
Slice Header:
{
    array: 0xc0000d4000    // New memory address!
    len:   6               // Increased
    cap:   10              // Doubled (assuming old cap was 5)
}
 
New Backing Array at 0xc0000d4000:
[0|0|0|10|20|30|unused|unused|unused|unused]

The old backing array becomes garbage and will be cleaned up by Go’s garbage collector.