> And that interaction is absolutely a WAT

I'm not sure views into a fixed-sized array is really confusing/strange at all. Whether you create multiple views in the array, mutate the views, etc. All interactions that occur on slices and arrays make plenty of sense. How you'd write something like append yourself if "Slice" was your type w/ a backing array, a start index, and a length is quite straightforward.

This is absolutely one of the worst aspects of Go. When you call append() on a slice, and then modify the contents of the result, you may or may not modify the original slice.

In a language that encourages concurrency, this indeterminism should be jaw-dropping. How many Go programs are safe only accidentally via an array's allocation policy (especially given how much code it requires to duplicate a slice)? Can you think of any other language that has such a design?

It's not indeterminate, just conditional at runtime, no different than any other may-mutate-parameter-reference function. It fits Go's philosophy of foot guns for the sake of performance/simplicity (be it compiler or runtime performance/simplicity). Use of append by devs should invalidate any future uses of the parameter, but this is better than forcing a copy or abstracting implementation details of linked arrays.

> Can you think of any other language that has such a design?

Sure, happens all the time because it fits the machine naturally though sometimes it may be hidden with unnecessary runtime costs by many languages that do force copies or reallocations due to immutability. C++ is a language that doesn't hide it. Your argument is like saying you're surprised that std::vector::emplace_back may or may not alter the array I had kept from std::vector::data previously.

> I'm not sure views into a fixed-sized array is really confusing/strange at all.

Again, as I already stated in the previous comment the issue is not the slices themselves.

It's that they're doubling up as vectors and they're shitty at it: you can share a backing buffer between mutable slices and append to both and then all hell breaks loose.

That is the issue. And that is why Rust doesn't have that issue despite having the same concept of slices: you can't grow a slice, and you can't have multiple mutable slices to the same backing buffer.

I mean, by that measure C/C++ and many others have the same problems. Your issue about lack of compiler-enforced reuse checks after invalidation is more with the language than this feature. While I agree generally, I don't see how slices are any more of a problem or surprising here than any other mutable reference that may or may not be mutated conditionally by a function.

> I mean, by that measure C/C++ and many others have the same problems.

No. C only has raw pointers so it's not trying to pretend slices are vectors, and C++ has actual functioning vectors with "slicing" being either a copy of the subvector or an iterator. Either way there is no confusion as to the capabilities of what you're given and its relation to the original data.

> Whether you create multiple views in the array, mutate the views

Whether there are multiple views or not is actually an implementation detail, and whether "append" chooses to allocate memory or not will change whether there are multiple copies or multiple views of the array.

All of that behavior is something you absolutely cannot rely on.

Can I not rely on append only allocating when the values to append won't fit in the remaining capacity of the underlying array starting from the end of the slice? Some articles indicate this and definitely don't seem surprising [0]. Granted I don't know the implementation details, but how do copies of the array or numbers of slices of the array affect that? Regardless, with Go as opposed to lower level languages, building reliance on whether functions do memory allocation (even built in ones) is folly.

0 - https://blog.golang.org/go-slices-usage-and-internals

The behaviour of append and the conditions where it will allocate a new backing array are specified and part of the language. Implementation details don't even enter the picture here. You can absolutely rely on that not changing.