(Memory) safe languages are allowed to guarantee memory safety at any stage, including at runtime using GC and bound checks. That makes every GC language memory safe to a reasonable extend. The novelty in Rust is that it does the same at compile time, mostly automatically.
You can have data races in "safe" Go. If you race a trivial object [such as an integer] it's just radioactive and so long as you didn't need it to have any particular value (e.g. you were just going to write it to a log anyway, or you just discard it) you're fine. However if you race a non-trivial object then that's immediately Undefined Behaviour.
Of course Go programmers will say "Just don't do that" but that's exactly what C programmers told us about bounds misses, use after free and so on...
While I have seen this pattern occur in many software projects I have worked on, I find your implied solution cannot possibly work; bringing everyone to the lowest common denominator can not possibly yield extraordinary results.
The example you put forth, namely rust vs golang is great; rust is an extraordinary tool.. in the right hands. So no, it is not for the average programmer. You need years of experience to see why rust is a great language and framework. To understand the why. Instead of ditching the Jedi and the light saber with it would be a better approach to understand how to leverage the extraordinary individual without alienating the entire base team. Define boxes where they can contribute as individuals who own key components.. alone. Team work is not for everyone ;-)
