You don’t need to use 'unsafe' yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe.

The situation with Go is pretty clear. Channels are safe. If you start mutating shared state across different goroutines, then you’re in the same situation you’d be in if you were doing the same thing in C++. Anyone who doesn't understand why that's potentially unsafe wouldn't be ready for Rust in any case.

> You don’t need to use ‘unsafe’ yourself in Rust. Any package that you’re using might contain unsafe code that its author believes (rightly or wrongly) to be thread-safe.

Sigh. That's true of Go too. Both Rust and Go have `unsafe` labels that give access to dangerous things that can cause UB. Both Rust and Go are susceptible to UB-at-a-distance if library code internally uses `unsafe` incorrectly. The difference is that, in Go, you can write code with data races without using any `unsafe` at all. Nothing will yell at you (unless you exercise the race in a test and run the race detector). Rust does not suffer from this flaw.

I've been writing both Rust and Go since before each had their 1.0 release, and I like both languages. This isn't some back-handed comment about how I think Go is bad because of this. I rarely trip over data race related bugs in Go, but they do happen, so they aren't a huge issue in practice. (And your continued mention of channels is a red herring. Go has mutexes and idiomatic code uses mutexes quite frequently. Channels are not always the right thing to use.) Nevertheless, the comments here comparing Rust and Go are a fairly important mischaracterization of how each language treats memory safety, and it's important therefore to correct that.

>Sigh. That's true of Go too.

Yes I know. I'm not sure why you think I'm saying that this is not true of Go.

>The difference is that, in Go, you can write code with data races without using any `unsafe` at all

Again, I know. I addressed this in my previous comment.

Less sighing, more reading!

Yes, I'm sure you're aware. But the way your comments are written are pretty misleading, so I'm trying to clarify them. If you don't think the clarifications are beneficial to you, then treat them as clarifications for anyone else who is reading.

> Anyone who doesn't understand why that's potentially unsafe wouldn't be ready for Rust in any case.

That's most certainly not true. They might not be ready to write high performance generic data structures from scratch, but application level code in Rust generally has about as much explicit `unsafe` as application level Go code, in my experience. (And writing high performance generic data structures isn't really a thing in Go. Not nearly as much as in Rust anyway.)

I don’t think you are clarifying them so much as misreading them.

I'm confused by the second paragraph of your response. My point was that the lack of an explicit 'unsafe' block in Go isn’t that much of an issue, as pretty much everyone knows that Go does not make any memory safety guarantee when accessing shared state from different Goroutines. Anyone who doesn’t know this isn’t ready to get their head around writing multithreaded code in Rust. Rust’s features for doing this are cool, but they require a pretty good understanding of Rust’s complex type and lifetime system.

What a strange argument. "Pretty much everyone knows" that C/C++ aren't memory safe even for sequential code, and that it's incredibly easy to trigger thread-safety bugs in C/C++. But since "pretty much everyone knows", I suppose that makes it OK?

> Anyone who doesn’t know this isn’t ready to get their head around writing multithreaded code in Rust.

Well, if they aren't using `unsafe` in the process (or, to be fair, relying on buggy library code that uses `unsafe` inappropriately), they're not going to introduce memory unsafety via data races - no matter how "ready" they are. You just can't say the same about C/C++. Or even Go.

I don’t recommend that people use Go to write complex multithreaded code that accesses shared state. My point is that I doubt many people are doing this while erroneously thinking that their code is guaranteed to be memory safe. In other words, whatever the problems with Go may be in this regard, it’s not primarily the absence of an ‘unsafe’ keyword that’s the issue.

> I don’t recommend that people use Go to write complex multithreaded code that accesses shared state. My point is that I doubt many people are doing this while erroneously thinking that their code is guaranteed to be memory safe. In other words, whatever the problems with Go may be in this regard, it’s not primarily the absence of an ‘unsafe’ keyword that’s the issue.

I think the point here is that if the word "unsafe" exists as a language construct, someone is not wrong in assuming anything without that mark is safe. Otherwise, why isn't there a "safe" language construct?

That’s true to an extent, but it’s important to bear in mind that you can’t lexically scope memory unsafety. Rust code that doesn’t contain an 'unsafe' block should be safe assuming that all of the libraries it’s built on are safe. But those libraries may well contain 'unsafe' blocks that are (one hopes) carefully written to be memory safe.