Slice with a Pinch of Salt?

Go is unlike any other language. Often programmers have a muscle-memory of doing certain things in a certain way in their native language — like Python, Ruby, Javascript, etc. — and they try to re-apply the same in Go, and end up feeling skeptical about the whole idea. Well, Go is different! It is swift like others, but is also capable as a system programming language.

One such case is the Slice [1] specification in Go.

Most languages, like Python, create another copy of the underlying array when any of the slices pointing to it does a write. This is classic Copy-on-Write (CoW) operation.

Go takes a more lean and lazy approach in doing this. It keeps modifying the same underlying array until the capacity of a slice is reached. What do we call this, Copy-on-Capacity-Overload (CoCO)?

Yes, this could be a weird semantic, and seems to be implementation specific. Strangely, the spec only defines limited behavior (as below), and does not say much on how multiple slices may or may not refer to same underlying array depending on when the append hits capacity. More on this after the examples.

If the capacity of s is not large enough to fit the additional values, append allocates a new, sufficiently large underlying array that fits both the existing slice elements and the additional values. Otherwise, append re-uses the underlying array. [1]

Continue reading “Slice with a Pinch of Salt?”

Golang: Handy Stack Trace

Go can feel indispensable and tempting at times, and it has only got some makeshift-debuggers, here and there — nothing full-fledged. If you try debugging through tens or hundreds of goroutines, it becomes even more confounding and hairy!

A little bit of runtime, a little bit of reflection, that’s all it is.
Continue reading “Golang: Handy Stack Trace”