alt Hacker NewsSure, but a data race is, IMHO not the same as memory safety. A data race, can be 100% memory safe, but just cause a logic bug in some program. I often see people mixing memory safety with racing. Go has bounds checks so you end up with a panic either way. Not UB.
As an (outside go) example, Ocaml (5) promises strong memory safety, but not to be data race free. A data race is not something we can prevent, because its usually not bound by code, but by time and the race-source rarely in source-code.
This means we have data races in http, database inserts etc. The source is usually not a concurrent task in source code-land.
Replies
Races can be memory safe (they are in Java and Ocaml), but in Go they can indeed cause UB.
https://go.dev/ref/mem#restrictions:~:text=such%20races,corr...
https://www.ralfj.de/blog/2025/07/24/memory-safety.html (I don't agree with everything here, but it's a very thorough explanation)
Russ Cox points out that races are the one place in Go besides unsafe where Go lacks memory safety: https://research.swtch.com/gorace
I do think the nitpicking about this is mostly from people that want to say “my favorite language is safer than Go” which stupid and annoying.