Thoughts on Go slices and beginner’s mind

Beginner’s mind can be such a gift, if I can get over myself to enjoy it. I think some of the best explanations to things come from someone who just had that POOF a-ha! moment when you really get something for the first time. Acting like we all Kool-aid man burst into being knowing everything doesn’t really help us, or anyone else, even (especially?) when it’s the “simple” stuff.

If I have the goal of blogging weekly, and some of the things I found most interesting that week (or at some point) were “beginner” things, then are they not valuable? And in addition, is this not my corner of the Internet anyway, to do with what I want?

And so, the “beginner” stuff I wrote down a few weeks ago that I found interesting: arrays vs. slices in Go.

A few weeks ago I was doing some array operations, or so I thought. This led to re-reading some of the intro-to-Go docs and I wrote down:

If it doesn’t have a number, it’s not an array, it’s a slice

Me, a few weeks ago

// This is an array
var x = [3]string{"a","b","c"}
// This is a slice: note how it has no number between the []
var y = []string{"d","e","f"}

Here’s a playground (the easiest way to share Go code, afaik, I would sure love a REPL) of the above.

In practice, pretty much everywhere my mind was seeing arrays, in Go, are slices. I went and read up in Effective Go about slices, and learned a bit I’ll basically rephrase here, for learning purposes.

An array in Go is explicit: I’m saying “hello computer, I would like this many slots for things please, and every time I’m talking about it, I’m talking about the values of the array.”

That’s where the two key (practical) differences are, to me: defining the size (hence: “if it doesn’t have a number…”) and passing values around. According to Effective Go:

[M]ost array programming in Go is done with slices rather than simple arrays.

Effective Go

If we assign an array to another value, the whole shebang gets copied, but if we assign a slice, the two slices are pointing at the same array. We can see this in practice:

var x = [3]string{"a", "b", "c"}
var y = []string{"d", "e", "f"}
a := x
b := y
a[0] = "tree"
b[0] = "poplar"
fmt.Println("array", x)
fmt.Println("slice", y)
fmt.Println("array assigned", a)
fmt.Println("slice assigned", b)

If you’re reading this, before you click “Run” in the playground link, what do you think will be printed for x, y, a, and b?

Which means if you are using arrays (which according to Effective Go, you probably aren’t), you probably want to be passing pointers around, so there should be some & and *s around your code, because you probably don’t want to be creating lots of copies of an array (because that would be wasteful from a performance perspective).

Fortunately/unfortunately/interestingly, it’s neat to learn about the underlying data structure to slices (since according to this rabbit hole, and general experience thus far, I’ll rarely see arrays).

I also wrote (in this corner of note taking I’m looking at) that I learned about Go tags, which I recall was from seeing them all over the AWS Go SDK and those bits of text looking like they were probably useful. Maybe that’d be a good next topic?