In all languages if you cause a data race you lose Sequential Consistency. Java's experience teaches us that even if you go to extraordinary lengths to ensure that everything else is still fine, programmers cannot reason about non-trivial software without Sequential Consistency and so now they can't fix it. In something like C or C++ all races are Undefined Behaviour, all bets are off. In Go as we saw some data races aren't immediately dangerous but even if you're careful you do lose Sequential Consistency and so good luck doing anything when you don't understand what your program means any more.
> And for these, we have tons of solutions
If you put the solution in place and thus prevent a data race, you don't have a data race. Now, when was the last time you wrote a program in which you got everything right first time?
I wasn't thinking specifically about Go for this example, but alas Go's strings aren't trivial objects, and so this data race would be immediate UB in Go, whereupon "Susan Sarcemin" while still very unlikely is not impossible. The text (underlying rune slices? really? I guess that would be on brand but it's a bad idea) isn't getting mutated, but your string typed value is, and that is a non-trivial object.
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.