> It's memory safe due to the GC

That gets debatable as soon as you start using concurrency, like I said. There are idiomatic patterns in concurrent Go that are very much not safe.

What do you mean?

It has a GC, right? So use-after-free is impossible, no?

On the other hand, Go code is a lot easier to audit.

The kind of logic bug that the Rust compiler prevents due to stronger typing is typically a crash in Go, not a security issue.

Disagree on this. In Rust I can read most of the information I need to know straight from the function signatures. In Go I have to go through every line of code (and there are often a lot of lines due to Go's lack of expressive power).

In Rust code I audit, I typically have to jump through multiple layers of abstraction and cleverness, while Go code is straight forward and boring.

I guess it's a matter of preference. If something is abstracted, then you only have to audit it once (and often you can count on someone else having audited it). With Go code, everything is new and unique, so there are a lot more opportunities to introduce bugs.

Not to be argumentative, honestly, that sound pretty laughable if you don't have an equivalent of an algebraic effect system (or similar).

A "function" in Rust can do a whole bunch of stuff that is not signaled by its type signature.

Mutability / immutability is in the function signatures, and that goes a long way. It's not as good as an effect system of course. But along with global variables barely being a thing in Rust, it goes a long way to cutting out the common course of bugs.

Rust is not safer than Go, people thinking otherwise misunderstand borrow checker vs GC.

Furthermore you're talking about memory safety vs business logic bugs, two different things.

Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior.

I haven't heard of this causing a problem in practice, though.

I never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption.

Please give us a code example.

Here's a blog post from Russ Cox (Go core team) explaining it: https://research.swtch.com/gorace

Here you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.

Yes, not synchronizing a slice can lead to memory corruption in Go.

Slice values are normally copied so it's not an issue. The slice would need to be stored in a global or a struct's field and then changed while some other goroutine is reading it.

(I haven't seen this happen, though.)

Are all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.

Unfortunately slices are 3 words. (Besides, AArch64 isn't a common target for Go. On x86 you'd need cmpxchg16b or something.)