> Another great aspect of concurrency in Go is the race detector. This makes it easy [emphasis mine] to figure out if there are any race conditions within your asynchronous code.
It can be a bear to try and track down some race conditions but at least it will not report false positives. However, it will not catch all race conditions or data races you may have.
Is Go even memory-safe in the presence of data races? Don't get me wrong, “memory safety” isn't a hard requirement in my book, but “memory safety or a formal semantics” is.
If you're curious, the behavior is well defined: golang.org/ref/mem
My English reading comprehension is admittedly poor, but I don't see any portion of the text that automatically implies that unsynchronized reads and writes are atomic.
You know there are but that's the end - still not easy to reason about them haha!