3 ms·
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 th
by 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 agoThere 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 agoHow 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 agoI gave you a definition in my initial reply to you.
- howinteresting 6y agoRust 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.