Earlier quoted context omitted.
Go and Rust are better at different things. Go uses garbage collection, while Rust uses manual memory management with borrow-checking to ensure safety. Both are just as safe, but garbage collection is slower while Rust's manual memory management requires a lot more effort on the part of the developer. In particular, the performance of garbage collection is less predictable, making Go unsuitable for things like audio…
> Both are just as safe With a single execution context this is true. But, whereas you simply can't write data race bugs in Safe Rust† in Go you can write them and they blow up your safety guarantees. If you race something trivial Go promises (unlike C or C++) that this doesn't immediately set fire to the world, the raced trivial object (say, an integer) is ruined and you must not touch it, but if you stay away from…
That said, I'm not sure why developers freak out over races so much. Races that result in simple display of data that's one nanosecond old is typically not a failure condition in most applications. Actual failure conditions from races are usually from read-operate-writes like increments/decrements/etc. And for these, we have tons of solutions, anywhere from atomics to transaction contexts to CRDTs, etc.