Rust has a different notion of memory safety than the Java or Go memory models. In fact, compared to Rust's memory model, both Java and Go are memory unsafe (in the Rust sense of safety, not the traditional sense)

Namely, Rust's notion of memory safety prevents data races in concurrent programs. This is because Rust's region typing / lifetime system rejects racy programs as invalid.

Go provides something more like a built-in concurrency framework than truly baking this sort of safety into the language. It's just as possible to write racy concurrent programs in Go as it in in Java, C++, or C.

Go provides idioms that can help you avoid writing racy programs, but they're just that: ideas about how to structure your program, not guarantees that will keep you from shooting yourself in the foot.

Go provides a data race detector so if you do write racy programs, you can retroactively detect the problem. Unfortunately data races have this nasty tendency to pop up under unusual circumstances like high load or unusual combinations of events.

That the author of this post chose concurrency as the thing to harp on about Go's superiority shows how little experience that person has with Rust, IMO. Rust shares the same basic concurrency concepts as Go (communicating sequential processes), but features a compiler whose type system prevents you from writing racy concurrent programs.