You are right in that ptrace is slow and nasty. The key problem, I believe, is the tracer-tracee mode that involves two host processes and the switch is asynchronous (ptrace(SYSEMU) and then waitpid).
We do have the KVM platform that offers the synchronous switch, which performs better if you have bare-metal virtualization support.
The former is a set of kernel libraries derived from NetBSD, and the latter is a Unikernel built based on the former. gVisor is different in a couple of ways: 1) gVisor is written from scratch using Go for its memory and type safety; 2) gVisor tends to be compatible with Linux which most people use. In theory, gVisor can be restructured as a Unikernel, but we still like to pertain the ring privilege boundary for additional isolation. We are working on an academic paper which will have more details.
This is true, Go is not memory safe in the presence of data races, and data races are possible in safe Go.
But they're also generally easy to code-review out. There's definitely a huge difference between C and Go, regardless of this one caveat to Go's memory safety guarantees.
They aren't using single threaded Go from what I can see.
Data races are not easy to "code review out". That is contrary to decades of experience. All you have to do in Go to get a race is to close over a for loop induction variable in a goroutine.
There is not a large difference between C and Go here. In fact, races might be easier in Go than in C, because it's easier for goroutines to close over mutable variables.
> I haven't really seen this as a big problem in Go.
Go certainly does have problems with data races all the time. Just Google for "golang data race": you'll find many blog posts explaining common data race gotchas in Go.
> Regardless, I think there's a world of difference between C and Go when it comes to memory safety.
We do have the KVM platform that offers the synchronous switch, which performs better if you have bare-metal virtualization support.