I think the issue is a bit more subtle than you're suggesting because Rust (as you know) only promises to eliminate the problem in safe code. Go doesn't have th

I think the issue is a bit more subtle than you're suggesting because Rust (as you know) only promises to eliminate the problem in safe code. Go doesn't have the same type infrastructure for stopping you from accidentally sharing data between multiple threads, so it doesn't have the same sharp distinction between 'safe' and 'unsafe' concurrency options. But it's also not as if Go's concurrency story is just 'share data and hope for the best'. Idiomatic Go code should be using channels. In short, both languages let you write memory unsafe code if you want to, but both discourage it and make it easy not to do so in most cases. Rust discourages it in a more bondage and discipline kind of a way. But it still falls to the programmer to verify the unsafe kernel of their application to their satisfaction. That is, Rust provides a 'here be dragons' warning by forcing the use of an 'unsafe' block, but the language itself doesn't offer any assurances about the correctness of an application's kernel of unsafe code. Modern async Rust doesn't uniformly discourage the use of idioms that make use of unsafe code. See for example the discussion of stack pinning here: https://rust-lang.github.io/async-book/04_pinning/01_chapter.html https://rust-lang.github.io/async-book/04_pinning/01_chapter... ("A mistake that is easy to make is forgetting to shadow the original variable since you could drop the Pin and move the data ... (which violates the Pin contract).") I'd advise against inferring that people "don't care" about these problems, etc. etc. This kind of personal stuff just makes it harder to focus on the technical details.