Compilation speed matters, among other things, and monomorphization is often costly.

Slices are structures that hold a pointer to the array, a length, and a capacity!

So, when you slice a slice, if you perform an array operation like “append” while there is existing capacity, it will use that array space for the new value.

When the sliced value is assigned to another variable, it’s not a pointer that’s copied, it’s a new slice value (with the old length). So, this new value thinks it has capacity to overwrite that last array value - and it does.

So, that also overwrites the other slice’s last value.

If you append again, though, you get a (new) expanded array. It’s easier to see with more variables as demonstrated here: https://go.dev/play/p/AZR5E5ALnLR

(Sorry for formatting issues in that link, on phone)

Check out this post for more details: https://go.dev/blog/slices-intro

It's because slices have underlying arrays which define their capacity (cap(s)).

Both slices start out having the same underlying (bigger) array -so appending to one slice can affect the other one.

In the "bonus" part, though, the appends outgrew the original array, so new underlying arrays were allocated (i.e. the slices stopped sharing the same backing array).

Thanks for the heads-up, janosdebugs :)

Yes-ish? Slices are this weird construct where they sometimes behave like references and sometimes not. When I read the explanation, it always makes sense, but when using them it doesn't. For me the rule is: don't reuse slices and don't modify them unless you are the "owner" of the slice. Appending to a slice that was returned to you from a function is usually a pretty good way to have a fun afternoon debugging.

I am not used to writing code where 2/3 of it is "if err" statements.

Also, refactoring my logging statements so I could see the chain of events seemed like work I rarely had to do in other languages.

It's a language the designers of which - with ALL due respect - clearly have not built a modern large application in decades.

> Code generation in Golang is something I've found removed a lot of boilerplate.

Not a gopher by any stretch, but to my way of thinking code generation is literally boilerplate, that's why its generated. Or does Go have some metaprogramming facilities I'm unaware of?

Not the parent, but I find that doing dependency injection or defensive programming results in a lot of boilerplate. Custom error types are extemely wordy. The language also doesn't allow for storing metadata with types, only on structs as tags, which seriously hampers the ability to generate code. For example, you can't really express the concept of a slice in a slice containing an integer needing validation metadata well. You'll need to describe your data structure externally (OpenAPI, JSON schema, etc) and then generate code from that.