Mutating shared state without synchronization is a bug with or without this proposal. Goroutines already run on potentially different OS threads or processors with the current m:n scheduler implementation.

"I am afraid that introducing non-deterministic preemptive stops will just make Go concurrency a mess similar to the mutex/conditionals mess they've been trying to avoid."

They already took a few steps inside of Go to try to ensure that concurrency is quite non-deterministic. Even very simple, naive code like

    func main() {
        for i := 0; i < 2; i++ {
            go func(j int) {
                fmt.Println("First", j)
                fmt.Println("Second", j)
            }(i)
        }
        time.Sleep(100*time.Millisecond)
    }

will very frequently produce different results; I just ran that four times and got four different results. This is good, because it tends to bring bugs to the forefront more quickly, rather than having a almost-but-not-quite-deterministic model as has been the case in many other environments.

(Yes, I know sleep is not production-quality here, just trying to keep it simpler than several more lines for a proper waitgroup usage.)

I doubt there's a lot of code written at the Go level that would explode if you suddenly ran it with a pre-emptive runtime that isn't already exploding. As the proposal discusses, there's a lot of issues down at the runtime level, but at the layer of abstraction presented by the language itself I wouldn't expect a lot of problems. Non-zero, and even then, it would still be things that are technically already bugs. And Go code is already running concurrently all the time in the real world. I'm not even sure how I'd construct an example that runs correctly in the current runtime but fails with true pre-emption.

Go code is not shared-state safe in the way that, say, Python generators are. And with the -race compile flag, it does a pretty good job of detecting violations so you can fix them.

So I think Go code should be unaffected by this change.

> I am afraid that introducing non-deterministic preemptive stops will just make Go concurrency a mess similar to the mutex/conditionals mess they've been trying to avoid.

It already is exactly that (Go already does m:n scheduling, so while your routine currently can't get interrupted between two function calls, two goroutines running on different OS threads can manipulate the same mutable state without synchronisation and make a mess of it), it's just that you don't necessarily notice.