Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior.

I haven't heard of this causing a problem in practice, though.

I never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption.

Please give us a code example.

Here's a blog post from Russ Cox (Go core team) explaining it: https://research.swtch.com/gorace

Here you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.

Yes, not synchronizing a slice can lead to memory corruption in Go.

Slice values are normally copied so it's not an issue. The slice would need to be stored in a global or a struct's field and then changed while some other goroutine is reading it.

(I haven't seen this happen, though.)

Are all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.

Unfortunately slices are 3 words. (Besides, AArch64 isn't a common target for Go. On x86 you'd need cmpxchg16b or something.)