This is why I love Go. Nobody was asking for this, but they took the time to do it right and continue to Push go as a memory safe, high-level systems language.
You can write unsafe code in Go (import unsafe), but then, you can do the same in Rust. Unsafe code is not the default, and in day to day Go i rarely see the use of the unsafe package.
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.
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.
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.
I 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.
Not 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.)
u8 · · focus · HN ↗
OutOfHere · · focus · HN ↗
shikck200 · · focus · HN ↗
iambvk · · focus · HN ↗
shikck200 · · focus · HN ↗
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.
saagarjha · · focus · HN ↗
shikck200 · · focus · HN ↗
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.
senderista · · focus · HN ↗
I think this should make the distinction between data races and race conditions pretty clear.
phplovesong · · focus · HN ↗
Not sure why you would be that nitpicky for something so trivial?
senderista · · focus · HN ↗