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.
<a href="https://www.ralfj.de/blog/2025/07/24/memory-safety.html" rel="nofollow">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)
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.
speedstyle · · focus · HN ↗
<a href="https://go.dev/ref/mem#restrictions:~:text=such%20races,corruption" rel="nofollow">https://go.dev/ref/mem#restrictions:~:text=such%20races,corr...
<a href="https://www.ralfj.de/blog/2025/07/24/memory-safety.html" rel="nofollow">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)