Also, data races in Go are trivially addressed using the common pipeline / CSP pattern, since channels are serializing. Of course, it doesn’t eliminate the possibility of doing stupid concurrency things, and you could of course argue that giving users trivially easy concurrency primitives encourages stupid concurrency, but I think it is fair to say that in most cases, Go idioms and primitives make race-free concurrency pretty easy. You have to go out of your way to write racy Go, and there’s nothing really preventing people from going out of their way to write unsafe Rust, either.

Strange, I've worked on complex projects in the distributed space with Go and it's very easy to catch these things with `-race` and linters.

nil dereference isn’t unsafe.

It's undefined behaviour, which is even worse!

Nope. Nil deref in Go is checked, and simply panics, just like array access out of bounds.

I have seen more leaks in the golang project I currently work on than in most C++ codebases I've worked with in my career. It's trivial to leak stuff in golang, and much more difficult to make sure that you don't

Ok? Is it not trivial to leak in unsafe rust? Managed memory is safety.

And it's trivially easy to ignore an error.

Also channels and WaitGroups are easy to misuse (well, that's why there's also an ErrGroup now).

I'd make Golang my 100% go-to language if it got rid of several footguns.

Though let's be real, that's absolutely certain to never happen, they take their backwards compatibility extremely seriously. So we'll have to keep relying on checkers and linters that alleviate some of the pains somewhat.

I'm not aware of any serious Go project without linting and tests.

In fact, most projects I've worked on won't even merge a PR with ignored errors.

Also, `go test -race` is a Go feature, there's nothing wrong with using it.

go test -race is awesome and everyone should use it.

But it's worth remembering that it's a dynamic analysis that only covers access patterns created by your tests.