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.
There is no memory safety without freedom from data races. One is a prerequisite of the other. This is why languages like C# throw exceptions on unsynchronized concurrent access to some container types, and treat all property accesses as atomic.
> I have never seen real Go code (i.e. not code written purposefully to be exploitable) that was exploitable due to a data race.
And from tptacek in that same discussion [2]:
> The fact is that Go doesn't admit memory corruption vulnerabilities, and the way you know that is the fact that there are practically zero exploits for memory corruption vulnerabilities targeting pure Go programs, despite the popularity of the language.
u8 · · focus · HN ↗
__s · · focus · HN ↗
shikck200 · · focus · HN ↗
So whats your point here? Haskell?
simonask · · focus · HN ↗
typical182 · · focus · HN ↗
> I have never seen real Go code (i.e. not code written purposefully to be exploitable) that was exploitable due to a data race.
And from tptacek in that same discussion [2]:
> The fact is that Go doesn't admit memory corruption vulnerabilities, and the way you know that is the fact that there are practically zero exploits for memory corruption vulnerabilities targeting pure Go programs, despite the popularity of the language.
[1] <a href="https://news.ycombinator.com/item?id=44672003">https://news.ycombinator.com/item?id=44672003
[2] <a href="https://news.ycombinator.com/item?id=44672371">https://news.ycombinator.com/item?id=44672371
simonask · · focus · HN ↗