GC does not provide memory safety at a system level, it has the same issues as C++ in poorly programmed code once compiled. Also C++ has "memory safety" idioms similar to garbage collection through reference counting and RAII.

Google has a C++ race detector based on the Go one and it did not detect this issue (or was ignored).

Neither of those things you listed reduce the severity of the bug, and both are available in well written C++ code as google tends to do.

What do you mean? If you don't use unsafe package you can't have the same problem as C/C++ so it is memory safe. The bug in Chrome can't happen in Go without unsafe usage.

That is categorically not true.

Go compiles down to machine code, it has a stack and heap, it has structures on that stack and heap, and it has data races; those are all of the required components for a use after free. You can have data races compiled by the stock go compiler without the use of unsafe (also, why have race detector tooling if this is false?). It would probably be easier to exploit than here even because one wouldn't even need to bother with the ASLR pointer exfiltration they had to do here.

It may be harder to write exploitable code, but memory safety does not guarantee runtime memory safety. Especially in the face of concurrency.

The race condition exploits you're thinking of are not trivial and need specific code to pull off, unlikely to be a mistake like in C/C++. You just don't find them in normal Go programs.

Source (scroll down to the conclusion section): https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Having race data in your Go code doesn't mean it will be exploitable like C or C++. Same reason with Java / C# when you don't use native code.