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.
Meh.. sure a DR is not the same as an RC, but i would class it as a subset of the same thing. You you cant have an RC, you cant have DR, but the other way around.
In the end its the same problem, dressed up differently.
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.
shikck200 · · focus · HN ↗
In the end its the same problem, dressed up differently.