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.
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.
In languages like C and C++.
I haven't really seen this as a big problem in Go. I know of one vulnerability involving this, personally. I haven't gone looking though.
Regardless, I think there's a world of difference between C and Go when it comes to memory safety.
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.
Agreed.
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.
I work on gVisor (TL/M and Co-Founder).