[ralfj]

Can you point me to the Go definition of memory safety? I searched all over their website, and couldn't find any.

(But also, it'd be kind of silly for every language to make up their own definition of memory safety. Then even C is memory safe, they just have to define it the right way. ;)

[kiitos]

For the purposes of this discussion, sure: https://go.dev/ref/mem

Relevant bit for the OP is probably:

    A data race is defined as a write to a memory location happening concurrently with another read or write to that same location, unless all the accesses involved are atomic data accesses as provided by the sync/atomic package. 

Which describes exactly what is happening in the OP's program:

    func repeat_get() {
        for {
            x := globalVar // <-- unsynchronized read of globalVar
            x.get()        // <-- unsynchronized call to Thing.get()
        }
    }

By itself this isn't a problem, these are just reads, and you don't need synchronization for concurrent reads by themself. The problem is introduced here:

    func repeat_swap() {
        var myval = 0
        for {
            globalVar = &Ptr { val: &myval } // <-- unsynchronized write to globalVar
            globalVar = &Int { val: 42 }     // <-- unsynchronized write to globalVar
        }
    }
    
    func main() {
        go repeat_get() // <-- one goroutine is doing unsynchronized reads
        repeat_swap()   // <-- another goroutine is doing unsynchronized writes
    }

Just a (chef's kiss) textbook example of a data race, and a clearly unsound Go program. I don't know how or why the OP believes "this program ... [is] according to Wikipedia memory-safe" -- it very clearly is not.

But, you know, I think everyone here is basically talking past each other.