undefined | Better HN

0 pointsbombela1y ago0 comments

Not sure how much it weighs on the balance in those types of decisions. But Rust has safe concurrency. That's probably quite a big boost of web server quality if anything else.

0 comments

jvanderbot1y ago

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.

thinkharderdev1y ago

(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

pjmlp1y ago

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.

1 more reply

umanwizard1y ago

> 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.

pjmlp1y ago

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

1 more reply

j / k navigate · click thread line to collapse