This is very common. Sharing memory is extremely important whenever you're doing anything related to CPU parallelism/concurrency; often if you don't use it you end up worse than the sequential algorithm.
It's surprising to hear you say this. I thought a design goal of Rust was highly discouraging shared-state concurrency. Has this design philosophy evolved somewhat over time?
> Has this design philosophy evolved somewhat over time?
Yes, it has. Post-1.0 Rust's design philosophy is about taming shared state concurrency: that is, disallowing data races statically, making sure you take locks or use atomics where possible, and having a robust set of generic concurrent data structures ready for use so you don't have to implement your own.
This article, for example, rightly observes that atomics are difficult to get right, making it not scalable to have every program implement concurrent data structures from scratch. The benefit of having a rich set of generic concurrent data structures readily available is that it mitigates this problem.
Makes sense! It's definitely a compelling story to offer the same abstractions that exist in other languages, but with static guarantees of correctness. A mutex that you can't mess up, that's a great thing.
Not at all. Rust gives programmers the ability to use shared state or channels at their discretion. The traits Send and Sync were made specifically for these use cases. Rust just guarantees that you can't use these primitives in an unsafe way.
Rust has very good support for shared-state concurrency. In fact, the borrow-checker is used to enforce invariants about locks and mutices that make shared-mutable-state a compile-time error.
