Hacker News Reader

Comment by shikck200 | Hacker News Reader

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.

View on HN

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.

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.

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.)

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.

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.

Reply on news.ycombinator.com