I think data-races that can cause undefined behavior are limited to maps and slices and other structures that internally use unsafe.

data-races that can't cause undefined behavior are a different class, closer to what java has, and iiuc that's what you get without unsafe.

I don't think the distinction matters, but I think it exists.

The slice is simply unsynchronized, so a user of the slice may pull out one array but a length that was for a different array.

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

They use `unsafe.Pointer`s under the hood, but I'm pretty sure that implementation detail is unrelated to the race condition (the issue with the race condition is that writes of these types aren't atomic so a concurrent thread that is reading the value could observe it in a partially-updated state (e.g., the pointer field has been updated but not the length field).

As far as I understand all interface pointers in go are fat pointers to (vtable, object) and as such can't be updated atomically [1]. Hence any data race on assignment to an interface pointer can lead to UB.

[1] unless there is an additional indirection, I don't really know much about go.