[nyanpasu64]

Rust is a brilliant lesson in using traditional threading safely. It uses & for thread-shared types and constrains &mut to a single thread, which naturally causes people to keep single-threaded data on an object only accessible from a single thread, and make multithreaded data either immutable, mutex-protected, or atomic.

Alternatively, message-passing isn't traditional threading, but Erlang/Go-style languages are another way to approach concurrency or parallelism.

[Galanwe]

I don't quite see how Rust approach to multithreading is that amazing.

Rust does nothing to magically prevent race conditions for you. Rust safety does not encompass race conditions, starvation, etc.

What it does is defensively prevent you from sharing mutable variables without explicitly opting for it.

It's good for catching careless sharing issues, but not much more.

[nyanpasu64]

In my experience with multi-threaded programming, C++ code with "careless sharing issues" is often filled with multiple threads accessing the same object and relying on convention to avoid calling the wrong thread's methods, pervasive data races and unsynchronized variable access, mistaken use of mutexes on only one side of shared memory, and logical race conditions that require adding mutexes (risking deadlock) or rewriting code to address. Whereas Rust code tends to not have these issues to begin with (outside of the implementation of synchronization primitives), store reader and writer methods on separate handle objects, use Arc to manage cross-thread shared memory, and similar which makes the code either correct or tractable to learn and make correct.

I also struggle to understand the threading model of COM and C libraries like libusb (https://libusb.sourceforge.io/api-1.0/libusb_mtasync.html), though that might just be me, and each library tends to have a different threading model. Rust's Send/Sync is a 90% solution which you can learn upfront, is checked by the compiler, and applies to all libraries and works for most use cases.

[Galanwe]

> In my experience with multi-threaded programming, C++ code with "careless sharing issues" is often filled with multiple threads accessing the same object and relying on convention to avoid calling the wrong thread's methods

Right, I can see the kind of codebase you're referring to.

I don't see Rust as a magical weapon solving concurrency issues though. Namely because Rust (the compiler) has a very limited view of what happens in the lifetime of a multithreaded system, and no view at all of the lifetime of a multiprocess system.

Even when writing purely single threaded Rust, you quickly end up having to let go of the strictly static memory sharing checks and switch to dynamic ones.

I have yet to find a use case where Rust solves anything but the most blatant synchronization issues.

[nottorp]

> Alternatively, message-passing isn't traditional threading, but Erlang/Go-style languages are another way to approach concurrency or parallelism.

Qt signals/slots across threads is also message passing. Transparent to boot. Too bad you need to afford a lawyer on retainer to use it these days.

[raggi]

https://doc.rust-lang.org/std/marker/trait.Send.html

[miraculixx]

Great examples. Unfortunately that's not what the Python SC has decided to go for.