Russ Cox points out that races are the one place in Go besides unsafe where Go lacks memory safety: https://research.swtch.com/gorace
replyI 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.
Races can be memory safe (they are in Java and Ocaml), but in Go they can indeed cause UB.
replyhttps://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)
That’s a race condition, not a data race.
replyNow you are pushing pixels. A data-race IS a kind of race condition.
replyMy point is "races" happen all over. In concurrent code, databases, http and pretty much anywhere where you have some kind of timing, not scoped to a unit.
A race condition is an application invariant violation under concurrency, so it has no application-independent definition. A data race is unsynchronized access by two concurrent threads to the same memory location where at least one access is a write. Ergo, the definition of a data race has nothing to do with application logic.
replyI think this should make the distinction between data races and race conditions pretty clear.
A data race is by definition a class of an race condition. This is basic compsci literature, and there is no other way to put it, as even a non programmer can see the similarity.
replyNot sure why you would be that nitpicky for something so trivial?
I find this distinction extremely useful in practice because it explains why a static analyzer like Rust's type checker can prevent all data races but can do nothing about race conditions. (Similarly, a dynamic analyzer like ThreadSanitizer can detect data races but not race conditions, because it knows nothing about application logic.)
reply