[codys]

Go can have memory unsafety leading to arbitrary memory reads and writes by having an interface replaced by another thread (go interfaces use 2 words, one for the vtable and another for the data. It does not replace these in a thread safe way, so one can use a vtable to work with an unexpected data pointer.

Folks have shown this allows the kinds of arbitrary memory reads/writes that folks normally ban in their definition of memory safe (and this post's website has a definition does as well):

https://research.swtch.com/gorace

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

https://www.ralfj.de/blog/2025/07/24/memory-safety.html

[aw1621107]

"Effectively" is the key word in GP's comment - i.e., there are no known real-world vulnerabilities in Go code that are attributable to tearing on data races, so the claim is that that particular memory safety flaw does not exist in practice.

[codys]

Interesting interpretation of that phrase. I think saying "probabilistically memory safe" would be more accurate (and more clearly communicate that idea), because we're betting on when a known case of memory unsafety in the language will show up in some piece of software.