However:
> The first, exemplified by C and C++, is that programs with data races are invalid: a compiler may break them in arbitrarily surprising ways.
The problem isn't just the compiler. If you write code with a data race the CPU might break your program in arbitrarily surprising ways too. Go programs don't rely on your C++ compiler, but they do run on your CPU and not a virtual machine.
Is Go really going to be able to deliver defined semantics here in the face of that?
> The second, exemplified by Java and JavaScript, is that programs with data races have defined semantics, limiting the possible impact of a race and making programs more reliable and easier to debug.
This was definitely the intention. But, do the results match that intention? It seems like in fact Java programmers are still confused by what happened when there's a data race, even though the semantics of a data race in Java are more limited, they're beyond the conception of the programmer anyway.
Do you go less insane if you see only two Great Old Ones than if you were to see a host of them? Or does the distinction not make a difference?
Later this document proposes the new Go model should say:
> such races can in turn lead to arbitrary memory corruption.
That's a much worse outcome than in Java. So I'd be astonished if Go programmers are able to meaningfully debug a program in which a data race has smashed unrelated data structures. In fact, I'm dubious as to what difference is even left between "arbitrary memory corruption" and C++ undefined behaviour. Experts will sometimes draw on their experience to guess correctly what went wrong. Specialist instrumentation might help find your root cause. But these are the same in C++