[jvanderbot]

Go's concurrency is unsafe? Rust's concurrency is automatically safe?

I am not saying you're wrong, I just don't find it any better than C++ concurrent code, you just have many different lock types that correspond to the borrow-checker's expectations, vs C++'s primitives / lock types.

Channels are nicer, but that's doable easily in C++ and native to Go.

[thinkharderdev]

(Un)safe is a bit of an overloaded term but Rust's concurrency model is safe in the sense that it statically guarantees that you won't have data races. Trying to mutate the same memory location concurrently is a compile-time error. Neither C++ nor Golang prevent you from doing this. Aside from that

[pjmlp]

With the caveat that those data races are related to in-process memory being accessed by threads.

Which is quite good, but leaves out shared memory with other processes, or threads having data races with external resources, while corner cases they are quite common in distributed computing scenarios.

[tialaramex]

You've been really obsessed by this for a long time and I'd be interested to understand if there's some specific trigger, something weird you're doing where this seems to you like it's a data race, because I have never seen anywhere that I was like "oh, I guess this is a data race" when there's unsynchronized access across process boundaries.

[pjmlp]

Because it is touted as an universal truth "Fearless Concurrency" of how Rust beats all languages, when in reality it only applies in a very specific use case, that in the world of distributed systems it isn't even the main one we care about in regards to concurrent and parallel access to data.

So its supremacy above anything else is kind of relative, and always left of out context.

[tialaramex]

See I don't buy that it's not "the main one we care about". What kind of insane software is expecting Sequential Consistency for shared mutable data across processes? That's what I still don't have a clear picture of. I think what I've seen here is merely a race condition, which is just not a big deal.

Humans can't reason about data races because they're contrary to our normal understanding of the world, but an ordinary race condition isn't like that. Earlier I saw there was the nice cheese at the grocery store, but I wasn't sure if they had fresh bread so... I kept walking, when I reached the bread aisle I bought bread and then I went back but nope, somebody else bought the last of the nice cheese. Oh well. Race condition.

[pjmlp]

Well then Fearless Concurrency should be sold in a proper way.

In modern times the network is the computer.

[umanwizard]

> Go's concurrency is unsafe? Rust's concurrency is automatically safe?

Yes and yes...

Rust statically enforces that you don't have data races, i.e. it's not possible in Rust (without unsafe hacks) to forget to guard access to something with a mutex. In every other language this is enforced with code comments and programmer memory.

[pjmlp]

As long as that something is in the process's own memory.

[umanwizard]

Correct, rust doesn’t magically prevent all bugs. It just makes a large class of bugs harder to write.

[consteval]

.. but most concurrency is done in distributed systems, where Rust provides little to no protection.

Although making a Rust monolith would be great!