[staticassertion]

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.

[pcwalton]

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.

[staticassertion]

> That is contrary to decades of experience.

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.

[pcwalton]

> 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.

Agreed.