[jerf]

"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.

[notheguyouthink]

> 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.

I concur, they do this with maps too. It led to discovering a bug in our system where order was being implicitly depended on via a JSON Object -> Map conversion. Go randomized the map key order when iterated over, revealing the logic bug.

[lloeki]

> They already took a few steps inside of Go to try to ensure that concurrency is quite non-deterministic

I would not be surprised as they are already proactively ensuring things like map ordering are randomised so that people just can't rely on some deterministic ordering: run the example code here[0] multiple times and it produces not just a seemingly random result (as would be for a typical hash table) but a truly different result for each run.

[0]: https://nathanleclaire.com/blog/2014/04/27/a-surprising-feat...

[kardianos]

Yes, map iteration is explicitly randomized for just this thing.