An illustation of append being confusing: https://play.golang.org/p/WGwp2cM6E1B

This would have been a way better WAT.

Indeed, less 'confusing' and more 'broken'.

It's pass by reference 101 where by reference is actually passing a struct by value, and the struct has a reference to more data, so sometimes the backing data is updated and the struct isn't...

So, probably more like pass-by-reference-and-by-value 201.

Go is only pass by value. Much in the same way JavaScript is (the best description for JS, IMO, is reference by value).

Even if you pass a pointer, the pointer is explicitly copied to a new location in memory, which is why assignment to the pointer can overwrite the pointer, but not affect the original pointer (the memory location value inside the pointer-typed variable) outside the function scope.

Pass by reference is when assignment to a parameter name is transitive to the caller's scope, and can be seen in C#. [1]

[1] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Now that C# has ref locals, it's not really pass-by-reference so much so as C++-style (or Algol-68 style, if you go far enough) references that are implicitly dereferenced on access and cannot be rebound.

Go is not really 'pass by value' when passing slices. It just passes the pointer value instead of doing a deep copy(copying the backing array). When trying to grow a slice in a function, the result is unpredicted because of 'apend' implicitly choosing to allocate memory or not. In addition, it is not concurrent-safe to pass mutable data. To avoid the safety problem, you have to copy stuff and consequently suffer a performance penalty. A better way to solve the problem is to introduce immutibilty. If one day immutibilty is introduced in Go 2(or 3), i wish slices are really passed by value. Then everything is passed by value as default with the immutable data passed by reference. You can still use pointers to pass mutable data just like using '_' to explicitly ignore error handling.

Now in WAT 1,

    func grow(s []int) { // s is deep copied.
        s = append(s, 4, 5, 6)  // changing 's' does not effect original slice.
    }

Explicitly pass mutable slice,

    func grow(s *[]int) { // s is referenced.
        *s = append(*s, 4, 5, 6)  // changing 's' will always effect origin slice.
    }

Explicit is better than implicit.

In the given examples, it is. But I agree slices are complex in Go, probably the most complex thing for newcommers, and the main reason why I wouldn't recommend go as a first language.