3 ms·

There's a good argument to be made that Rust is safer in multithreaded scenarios than the JVM or .NET. Rust statically prevents inappropriate unsynchronized ac

by dbaupp 7y ago

There's a good argument to be made that Rust is safer in multithreaded scenarios than the JVM or .NET. Rust statically prevents inappropriate unsynchronized accesses for arbitrary APIs (for instance, the compiler will emit an error when attempting to mutate a non-concurrent object/data structure from multiple threads). Those VMs make unsynchronized mutations of individual memory locations work just enough to not be unsafe, but still allow arbitrary unsynchronized operations. These will likely end up with an incorrect result, even if there's no memory unsafety, and may completely violate any internal invariants of the object or data structure. This latter point means one cannot write a correct abstraction that relies on its invariants without explicitly considering threadsafety (it is opt-in safety), whereas Rust has this by default (opt-out safety). Rust has essentially adopted the C/C++11 concurrency model.

pjmlp 7y ago
Yes, it is one less failure point to worry about, but in my experience using the respective task libraries in distributed applications, most of the multithreaded access bugs lie on external resource usage, and those Rust does not prevent. Not saying that it isn't important though.
- dbaupp 7y ago
  Ownership/affine typing does allow modelling that, within a single program. For instance, the type representing a handle to the external resource can have limited constructors and limited operations, that will enforce single threaded mutations or access (including things like "this object can only be destroyed by the thread that created it").
  - pjmlp 7y ago
    Assuming you are accessing the distributed resource from multiple threads instead of multiple distributed processes, which is quite common in distributed architectures. Borrow checker doesn't help at all with process IPC. Plus all ML derived languages have good enough type systems to model network states, while enjoying the productivity of automatic memory management.

by dbaupp 7y ago

pjmlp 7y ago

Yes, it is one less failure point to worry about, but in my experience using the respective task libraries in distributed applications, most of the multithreaded access bugs lie on external resource usage, and those Rust does not prevent. Not saying that it isn't important though.

dbaupp 7y ago
Ownership/affine typing does allow modelling that, within a single program. For instance, the type representing a handle to the external resource can have limited constructors and limited operations, that will enforce single threaded mutations or access (including things like "this object can only be destroyed by the thread that created it").
- pjmlp 7y ago
  Assuming you are accessing the distributed resource from multiple threads instead of multiple distributed processes, which is quite common in distributed architectures. Borrow checker doesn't help at all with process IPC. Plus all ML derived languages have good enough type systems to model network states, while enjoying the productivity of automatic memory management.