3 ms·
> Hmm, I'll have to check that out. I don't know that I would call Rust's ownership model super easy to reason about, but it is nice that the compiler prevents
by azth 11y ago
> Hmm, I'll have to check that out. I don't know that I would call Rust's ownership model super easy to reason about, but it is nice that the compiler prevents you from doing so much stupid $#^&.
It's much better get compile time errors than deal with very hard to reproduce data races.
- kazinator 11y agoOnly, as usual, in situations when all else is equal. By the way, on a related note, data races themselves are easier to reproduce than the visible negative consequences of those races on the execution of that program. That's the basis of tools like the "Helgrind" tool in Valgrind. That is to say, we can determine that some data is being accessed without a consistently held lock even when that access is working fine by dumb luck. We don't need an accident to prove that racing was going on, in other words. :)
- catnaroek 11y ago> By the way, on a related note, data races themselves are easier to reproduce than the visible negative consequences of those races on the execution of that program. Perhaps, but a data race by itself isn't sufficiently loud to catch my attention (no idea about yours), unless it consistently has visible consequences during debugging - preferably not too long after the data race itself takes place. > That is to say, we can [emphasis mine] determine that some data is being accessed without a consistently held lock even when that access is working fine by dumb luck. By “we”, do you mean human beings or computers? And, by “can”, do you mean “in theory” or “in practice”? Also, “only when we're lucky” or “reliably”? > We don't need an accident to prove that racing was going on, in other words. What I want to prove is the opposite - that there are no races going on.