[sagichmal]

> They never say or imply something like "if you have a data race, anything can happen [including executing code on the stack]"

They absolutely do.

https://software.intel.com/content/www/us/en/develop/blogs/b...

Violating the memory model gets you undefined behavior.

> However, this does not rebuke my original argument, which assumes that most devs are not in the know. They do not know about slices being unsafe, nor do they know about happens-before

I just don't agree. Go programmers know that nothing is safe for concurrent access unless explicitly noted otherwise. They don't have any confusion about slices requiring synchronization.

Concurrent programming isn't trivial but neither is it impossible. And data races are critical bugs that can be subtle, but are straightforward to identify, and straightforward to fix.

[voidnullnil]

Okay, well your (wrong) semantic argument that "GMM violation = UB" is irrelevant, so I'll stop arguing against it other than hinting that there is not one single mention of the word "undefined" in the GMM spec. Back on topic: Go is not memory-safe. Your belief that "GMM violation = UB", where UB = memory corruption literally and by definition implies that Go is not memory-safe. Java (which is where the term "memory model" comes from) is memory-safe, C# is memory-safe. Go is not.

Dilettante programmers certainly do not know the following:

1. Go slices, strings, and interface values are unsafely non-atomic. It's documented on some obscure page (even the spec does not document it AFAIK, which is also broken).

2. What a data race is

Even if they know #1, they will still write code like: modifying a slice within a structure and setting a thread-shared pointer to point to that structure.

Again, most programmers are taught "things need locks, for reasons". At best, they will pointlessly lock things, then another programmer will come "debunk" them and remove the lock because "the thing being locked is atomic". Note how none of this involves any thought of the memory model. That's because they do not know it exists.

As for people who know #2, yes that is enough to avoid memory corruption without needing to know #1, however, they are not sufficiently informed how much data races matter (as executing shellcode is not an expected outcome of writes to your data being non observable).

[sagichmal]

> GMM violation = UB

This is definitionally correct (shrug)

> Dilettante programmers certainly do not know [that] Go slices, strings, and interface values are unsafely non-atomic.

Yes. They do. As soon as a Go programmer learns that there is such a thing as concurrency and "thread safety" they learn that nothing in Go is "thread safe" by default.

> Go is not memory-safe.

"Memory-safe" is not a precisely defined concept. Go is memory safe by some definitions, not by others.

[voidnullnil]

Thinking on: "[data races] are straightforward to identify"

It's a the same as the problem of knowing what data is used in what thread, which is hard and unsolvable by automation, so I doubt it's an easy problem.