Comment by iambvk
8 hours ago
What he probably means is data-races in go can result in memory/type unsafe accesses -- I suspect, likely due to slice types -- not sure if that is true/false.
8 hours ago
What he probably means is data-races in go can result in memory/type unsafe accesses -- I suspect, likely due to slice types -- not sure if that is true/false.
Sure, 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.
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.
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)
That’s a race condition, not a data race.
Now you are pushing pixels. A data-race IS a kind of race condition.
My 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.
3 replies →