News for hackers. Stuff that matters.
Re:Updating the Go Memory Model by anderskaseorg on Monday July 12, 2021 @04:51PM (#27814960)
A section of Java code with a data race can’t break anything that the same section of code couldn’t have been rewritten to intentionally break without using a data race. For example: it might throw an exception, loop infinitely, or return valid values that the programmer didn’t expect; but it cannot corrupt the internal state of the JVM, violate type-safety, fiddle with private fields, or access data that isn’t reachable from its own variables. Data races cannot be used to violate a security barrier between mutually untrusting sections of Java code.
Re:Updating the Go Memory Model by ngrilly on Tuesday July 13, 2021 @11:35AM (#27822237)
You're right. That's a big advantage of the JVM. It's memory safe even in presence of data races.

That post from Russ Cox (again) explains quite well why Go is not memory safe in presence of data races, and what should be changed to fix this: https://research.swtch.com/gorace