[tialaramex]

A tiny thing that's not relevant to this particular piece of work but is worth having in background when thinking about Go is that while Go would like Python typically be described as "memory safe" unlike Java (or more remarkably, Rust) it is very possible for naive programmers to cause undefined behaviour in this language without realising it.

Specifically if you race any non-trivial Go object (say, a hash table, or a string) then that's immediately UB. Internally what's happening is that these objects have internal consistency rules which you can easily break this way and they're not protected against that because the trivial way to do so is expensive. Writing a Go data race isn't as trivial as writing a use-after-free in C++ but it's not actually difficult to do by mistake.

In single threaded software this is no caveat at all, but most large software these days does have some threading involved.

[commandersaki]

I'm confused what you ascribe to as undefined behaviour. What does that mean in the Go context? There is no mention of what UB is in Go at https://go.dev/ref/spec .

[tialaramex]

With a race of a non-trivial object in Go you're violating assumptions of Go's language runtime. Physically impossible things can't happen because that's what physically impossible means, but stuff which is merely written down in a document like the one you linked is fair game for such problems.

In terms of concrete examples, this might allow remote code execution, arbitrary reads or writes of memory that you otherwise don't have access to, stuff like that.