From the former head of the Go security team [1]:
reply> 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.
Memory safety isn’t really about vulnerabilities. This thread is about Go, so I won’t go further into it here.
replyAre you saying any language that does not promise data-race freedom is memory unsafe? That would rule out almost every programming language.
replyI am, but you’d be surprised. All of the single-threaded languages are fine, for example. Very few languages are actually low-level enough to allow data races. C# and Java go to great lengths to avoid it.
replyRace conditions in general are another matter, and aren’t generally considered a requirement (though you can certainly create nasty bugs).
I have not written a line of Java in 15 years. But im pretty sure Java has threads? Once you have threads, you pretty much have data races.
reply Thread a = new Thread(() -> x++);
Thread b = new Thread(() -> x++);
a.start();
b.start();The claim is not there is no data races in Java programs. The claim is that Java programs are memory safe, because the underlying virtual machine memory model is free of data races.
replyGo does not have that.
(Of course also Java may suffer from memory safety issues on system boundaries to unsafe code and due to JVM bugs.)
deleted
replyI don’t know Java or the JVM, but if it’s anything like the CLR/.NET, this would either be compiled to atomic operations, or throw an exception.
reply