There are a handful of concepts every Go beginner wrestles with.
- Pointers.
- Interfaces.
- Goroutines.
And somewhere near the top of that list sits a deceptively simple pair:
Arrays and slices.
When I first started learning Go, I honestly thought they were the same thing.
Both stored multiple values.
Both used square brackets.
Both let me access elements by index.
So naturally, I asked myself:
Why does Go have two data structures that seem to do exactly the same thing?
Like many beginners, I searched for the answer.
Every explanation sounded something like this:
- Arrays have a fixed size.
- Slices are dynamic.
Technically...
That's correct.
But it wasn't helpful.
Knowing what they are isn't the same as understanding why they exist.
The real breakthrough came when I stopped thinking about arrays and slices as two competing data structures and started seeing their relationship.
Imagine a bookshelf.
The bookshelf holds the books.
It owns them.
Now imagine placing a transparent picture frame in front of just a few books.
The frame doesn't move the books.
It doesn't copy them.
It simply gives you a different view of what's already there.
That's exactly what a slice is.
Once that idea clicked, suddenly everything else made sense.
Why changing a slice sometimes changes an array.
Why append() sometimes behaves strangely.
Why Go developers almost always use slices instead of arrays.
And why arrays still exist in the language at all.
By the end of this article, you'll stop memorizing definitions and start thinking the way Go does.
Let's build that intuition together.
Arrays: The Bookshelf
Let's start with the bookshelf itself.
Imagine you've just built a wooden bookshelf with five shelves.
Not four.
Not six.
Exactly five.
Once it's built, changing the number of shelves isn't as simple as snapping another one on.
You'd have to build a completely new bookshelf.
That's exactly how an array works.
An array is a collection of values with a size that's decided the moment it's is created.
Here's an example.
package main
import "fmt"
func main() {
languages := [5]string{
"Go",
"Rust",
"JavaScript",
"TypeScript",
"Python",
}
fmt.Println(languages)
}
Output:
[Go Rust JavaScript TypeScript Python]
Nothing surprising yet.
But look closely at the declaration.
[5]string
Most beginners read that as:
"An array containing five strings."
Go reads it differently.
Go sees [5]string as the type itself.
That means these are completely different types.
[5]string
[6]string
Even though they both store strings.
The number isn't just information.
It's part of the type.
That tiny detail explains why arrays behave the way they do.
Go already knows exactly how much memory to reserve before your program even runs.
It's like buying a bookshelf with exactly five compartments.
The carpenter isn't expecting you to ask for a sixth shelf later.
The design is already finished.
Arrays Own Their Data
Here's another idea that confused me when I started learning Go.
Suppose you buy another identical bookshelf.
Then you copy every single book from the first shelf onto the second one.
Now you have two completely separate bookshelves.
Changing one won't affect the other.
Arrays work exactly like that.
Original
+------+------+------+------+------+
| Go | Rust | JS | TS | Py |
+------+------+------+------+------+
Copy
+------+------+------+------+------+
| Go | Rust | JS | TS | Py |
+------+------+------+------+------+
Let's see it in Go.
scores := [3]int{85, 92, 78}
copyScores := scores
copyScores[0] = 100
fmt.Println(scores)
fmt.Println(copyScores)
Output
[85 92 78]
[100 92 78]
Changing copyScores didn't affect scores.
Why?
Because Go copied the entire array.
Arrays own their data.
Whenever you assign an array to another variable or pass it into a function, Go creates a brand-new copy.
This is called value semantics, but don't worry about memorizing that phrase.
Just remember this:
Arrays own their bookshelf.
Every copy gets its own bookshelf.
No sharing.
No surprises.
And that's exactly where slices enter the story...
SOCIAL SHARE CARD GENERATOR