As someone who has tried doing multithreaded design with Arc/Mutex, this is a complete nightmare. You constantly get into deadlocks and performance is abysmal, because Mutex is serializing access (so it’s not really async or multithreaded any more).

[–] BB_C@programming.dev 1 points 1 year ago (1 children)

As someone who has tried doing multithreaded design with Arc/Mutex, this is a complete nightmare.

I myself often use channels. And pass owned data around.

I don't think anyone argues that Arc+interior-mutation is ideal. But it's the over-the-top language like "complete nightmare" that some may take issue with.

Note that I again make the distinction between Mutex, and all interior mutation primitives. Because Mutex is indeed a bad choice in many cases. and over-usage of it may indeed be a signal that we have a developer who's not comfortable with Rust's ownership/borrowing semantics.

You constantly get into deadlocks and performance is abysmal, because Mutex is serializing access (so it’s not really async or multithreaded any more).

Same note about Mutex specifically as above.
Avoiding deadlocks can definitely be a challenge, true. But I wouldn't say it's often an insurmountable one.
What crate did you use for interior mutability, async-lock, tokio, parking_lot, or just std?

[–] anlumo@feddit.de 1 points 1 year ago

I used parking_lot back then.