4 ms·

> global mutable state without synchronization is not allowed. That's the java model again. I don't want fearless concurrency, I want intentionally designed t

> global mutable state without synchronization is not allowed. That's the java model again. I don't want fearless concurrency, I want intentionally designed threads.

estebank 3y ago
It's not the Java model because Java just makes every operation atomic (from the point of view of the model, I'm sure the JVM and javac must do optimizations to avoid some of them), while Rust enforces that multi threaded access must be through atomic operations, but if there is no multi threaded access or the type is not meant to be used in a multi threaded context, that information is encoded in the type system. This might sound like an academic distinction, but it is different: the developer is in control. You could even go as far as lie to the type system and claim a racy type is actually thread safe. I wouldn't advice doing so, but I can't stop you.
- bsdpufferfish 3y ago
  I’m sure the rust version is more ergonomic. It’s great you can do it more safetly. But it’s a bad application design from the start.
  - pornel 3y ago
    That's an incredibly broad criticism aimed at some hypothetical solutions you imagine, not grounded in what Rust does. No language can stop an imaginary infinitely determined fool. Rust's restrictions, such as strict scopes of references and strongly enforced shared XOR mutable access, prevent many sloppy and careless designs that are possible in Java or C++. Rust also takes advantage of its type system, generics, and ecosystem to offer solid constructs for multi-threading. There are safe data parallelism libraries, task queues, thread pools, scoped threads, channels, etc. Users are well equipped to implement multi-threading properly, and as much as possible Rust steers users towards locally-scoped, immutable or share-nothing solutions.

4 ms·

> global mutable state without synchronization is not allowed. That's the java model again. I don't want fearless concurrency, I want intentionally designed t

by bsdpufferfish 3y ago

> global mutable state without synchronization is not allowed. That's the java model again. I don't want fearless concurrency, I want intentionally designed threads.

estebank 3y ago
It's not the Java model because Java just makes every operation atomic (from the point of view of the model, I'm sure the JVM and javac must do optimizations to avoid some of them), while Rust enforces that multi threaded access must be through atomic operations, but if there is no multi threaded access or the type is not meant to be used in a multi threaded context, that information is encoded in the type system. This might sound like an academic distinction, but it is different: the developer is in control. You could even go as far as lie to the type system and claim a racy type is actually thread safe. I wouldn't advice doing so, but I can't stop you.
- bsdpufferfish 3y ago
  I’m sure the rust version is more ergonomic. It’s great you can do it more safetly. But it’s a bad application design from the start.
  - pornel 3y ago
    That's an incredibly broad criticism aimed at some hypothetical solutions you imagine, not grounded in what Rust does. No language can stop an imaginary infinitely determined fool. Rust's restrictions, such as strict scopes of references and strongly enforced shared XOR mutable access, prevent many sloppy and careless designs that are possible in Java or C++. Rust also takes advantage of its type system, generics, and ecosystem to offer solid constructs for multi-threading. There are safe data parallelism libraries, task queues, thread pools, scoped threads, channels, etc. Users are well equipped to implement multi-threading properly, and as much as possible Rust steers users towards locally-scoped, immutable or share-nothing solutions.