5 ms·

The article talks way too high level and is written like a marketing people even the title sounds technical, for example: "Rust enforces thread-safety of all c

The article talks way too high level and is written like a marketing people even the title sounds technical, for example: "Rust enforces thread-safety of all code and data, even in 3rd party libraries, even if authors of that code didn't pay attention to thread safety. Everything either upholds specific thread-safety guarantees, or won't be allowed to be used across threads."

burntsushi 6y ago
That doesn't sound too high level to me. Maybe a small quibble is the definition of "thread safety," but a reasonable one would be, "no undefined behavior in the presence of simultaneous access." In other words, no data races. And that's absolutely true and consistent with Rust's definition of safety. Another small quibble might be that, "even if the authors of that code didn't pay attention to thread safety and didn't use 'unsafe'" would be more precise. It's not marketing speak.
- up2isomorphism 6y ago
  There is simply no way you can enforce "thread safety on ALL data", unless you pay unreasonable amount of synchronization costs, which in that case, is a trivial thing to accomplish. This is as same as some one tell you that you will never loose any money by investing a certain asset.
  - steveklabnik 6y ago
    How well do you know Rust, and how it works, and what it guarantees? Like, do you have a specific objection to the way Rust accomplishes this?
    - up2isomorphism 6y ago
      "thread safety for all data" is not even a well-defined term, I do not know what you are trying to argue about.
      - deleted 6y ago
        [deleted]
      - burntsushi 6y ago
        I gave you a definition in my initial reply to you.
  - howinteresting 6y ago
    Rust is a constructive proof that your assertion is simply false. It comes at the cost of some complexity—every Rust type carries thread-safety information with it—but the benefit is that writing correct parallel Rust code becomes very easy. What you cannot easily do in Rust is dynamically switch thread safety on or off.
pornel 6y ago
But this is true. I mean specifically about Send and Sync traits that have to be implemented on types for the compiler to allow them in multi-threaded constructs, like `thread::spawn` or Rayon's parallel iterators. If you write a library, and use e.g. thread-unsafe `Rc` or not-sure-if-safe raw pointers anywhere in your structs, the compiler will stop me from using your library in my threaded code. This is based on a real experience. I've written a single threaded batch-processing code, and then tried to make it parallel. The compiler told me that I used a GitHub client, which used an HTTP client, which used an I/O runtime, which in this configuration stored shared state in an object without a Mutex. Rust pointed out exactly the field in 3rd party code that would cause a data race. At compile time.

burntsushi 6y ago

That doesn't sound too high level to me. Maybe a small quibble is the definition of "thread safety," but a reasonable one would be, "no undefined behavior in the presence of simultaneous access." In other words, no data races. And that's absolutely true and consistent with Rust's definition of safety. Another small quibble might be that, "even if the authors of that code didn't pay attention to thread safety and didn't use 'unsafe'" would be more precise. It's not marketing speak.

up2isomorphism 6y ago
There is simply no way you can enforce "thread safety on ALL data", unless you pay unreasonable amount of synchronization costs, which in that case, is a trivial thing to accomplish. This is as same as some one tell you that you will never loose any money by investing a certain asset.
- steveklabnik 6y ago
  How well do you know Rust, and how it works, and what it guarantees? Like, do you have a specific objection to the way Rust accomplishes this?
  - up2isomorphism 6y ago
    "thread safety for all data" is not even a well-defined term, I do not know what you are trying to argue about.
    - deleted 6y ago
      [deleted]
    - burntsushi 6y ago
      I gave you a definition in my initial reply to you.
- howinteresting 6y ago
  Rust is a constructive proof that your assertion is simply false. It comes at the cost of some complexity—every Rust type carries thread-safety information with it—but the benefit is that writing correct parallel Rust code becomes very easy. What you cannot easily do in Rust is dynamically switch thread safety on or off.

pornel 6y ago

But this is true. I mean specifically about Send and Sync traits that have to be implemented on types for the compiler to allow them in multi-threaded constructs, like `thread::spawn` or Rayon's parallel iterators. If you write a library, and use e.g. thread-unsafe `Rc` or not-sure-if-safe raw pointers anywhere in your structs, the compiler will stop me from using your library in my threaded code. This is based on a real experience. I've written a single threaded batch-processing code, and then tried to make it parallel. The compiler told me that I used a GitHub client, which used an HTTP client, which used an I/O runtime, which in this configuration stored shared state in an object without a Mutex. Rust pointed out exactly the field in 3rd party code that would cause a data race. At compile time.