4 ms·

I partly addressed this in another comment already, but perhaps I can try to convey a bit more of why I'm completely unimpressed by that argument for my use cas

I partly addressed this in another comment already, but perhaps I can try to convey a bit more of why I'm completely unimpressed by that argument for my use case. First of all, the "Bad Things" aren't actually uniformly bad. In its zeal, Rust won't let you modify different elements of the same array from different threads (an issue that comes up almost immediately in the OP) even though you know with perfect mathematical certainty that to do so is perfectly safe. In the context of simulation code that's not nitpicking, it's a usecase that comes up all the time, I can't even think of a codebase I've worked on in the last 5 years that didn't have this pattern in it somewhere. I have never, ever encountered a data race bug in any of those cases (even though there are usually tests to cover it just in case), but switching to Rust would immediately force me to waste time (and code quality, in my view) on working around a language restriction. The same goes for read-after-free and most other memory safety features, because most of the reasoning there simply doesn't apply when you're dealing with statically allocated memory that's never freed, with static guarantees on sizes, etc. Rust is very deliberately designed to address safety and correctness issues that exist in a style of programming that's just completely orthogonal to what I do. There is some inevitably some overlap and it's always possible to construct a contrived case where Rust could potentially prevent a bug I could conceivably make, but the point is that everything I've seen leads me to conclude that any such benefit would be vastly outweighed by the time unnecessarily spent on working around non-issues, dealing with syntax verbosity and semantic baggage (I distinctly do not want the notion of "lifetimes" at the language level at all), all of which means more code and, in all likelihood, more bugs. All of this sounds very negative, but I really don't mean to be. If you buy into the dynamic allocation heavy style of programming Rust is designed to improve, Rust looks great. It also seems to have an educated and thoughtful user community for the most part, something I actually envy a bit. I just don't think people should fall into the narrow view of thinking that Rust is a universal good - it takes a particular approach, with very stringent limitations and the limitations aren't there because Rust is bad, they are there to make it great... just not for everyone.

pdpi 7y ago
> it's always possible to construct a contrived case where Rust could potentially prevent a bug I could conceivably make, but the point is that everything I've seen leads me to conclude that any such benefit would be vastly outweighed by the time unnecessarily spent on working around non-issues Yeah, I think at this point we're just agreeing very loudly :) Rust absolutely has some objective advantages over C++, as does C++ over Rust. The choice of which set of (dis)advantages works best is very much something that can only be determined on a case-by-case basis.
steveklabnik 7y ago
> In its zeal, Rust won't let you modify different elements of the same array from different threads (an issue that comes up almost immediately in the OP) even though you know with perfect mathematical certainty that to do so is perfectly safe. To be clear, Rust will let you do this, as long as you're communicating that you know this to the compiler. split_at_mut and scoped threads are two ways that this is possible without requiring you to write your own unsafe code.
- keldaris 7y ago
  Right, the OP solved this using Rayon's par_chunks_mut, then enumerate and foreach over that, so I assumed that's the most ergonomic way to work around the issue. I certainly wasn't claiming that there are no workarounds, merely noting that from my - obviously biased - point of view this looks like yet another annoying hoop to jump through. There's obviously the opposite point of view which holds this up as a useful safety measure and determining which is correct requires knowing the context you work in. Given the vanishingly tiny amount of time I've spent on debugging issues this restriction might have prevented Rust just looks very unergonomic to me, but the opposite perspective can be just as valid given the right context.
  - pixel_fcker 7y ago
    I think the key difference here is that in your code you’re saying you “know” that it’s safe to write to these certain sections of the array from different threads. That’s an invariant that‘s held in your memory (or in a comment maybe). The rust equivalent is doing the exact same thing but requires you to formalise that invariant in your code by using one of the methods defined above. I can see how initially this looks like an extra hoop to jump through but after using it for a while I’ve found the opposite is true: because those invariants are checked by the compiler it’s one less thing I have to keep in my head and I can concentrate on the real problem.
    - safercplusplus 7y ago
      And also one less thing to transfer to the heads of anyone else that might need/want to understand the code. (Often the author him or herself at some point in the future, right?) Though equivalent facilities are available in C++ [1][2] (and can now/soon be enforced[3]). [1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master/README.md#tasyncrasectionsplitter https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master/README.md#scope-threads https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [3] https://github.com/duneroadrunner/scpptool https://github.com/duneroadrunner/scpptool

pdpi 7y ago

> it's always possible to construct a contrived case where Rust could potentially prevent a bug I could conceivably make, but the point is that everything I've seen leads me to conclude that any such benefit would be vastly outweighed by the time unnecessarily spent on working around non-issues Yeah, I think at this point we're just agreeing very loudly :) Rust absolutely has some objective advantages over C++, as does C++ over Rust. The choice of which set of (dis)advantages works best is very much something that can only be determined on a case-by-case basis.

steveklabnik 7y ago

> In its zeal, Rust won't let you modify different elements of the same array from different threads (an issue that comes up almost immediately in the OP) even though you know with perfect mathematical certainty that to do so is perfectly safe. To be clear, Rust will let you do this, as long as you're communicating that you know this to the compiler. split_at_mut and scoped threads are two ways that this is possible without requiring you to write your own unsafe code.

keldaris 7y ago
Right, the OP solved this using Rayon's par_chunks_mut, then enumerate and foreach over that, so I assumed that's the most ergonomic way to work around the issue. I certainly wasn't claiming that there are no workarounds, merely noting that from my - obviously biased - point of view this looks like yet another annoying hoop to jump through. There's obviously the opposite point of view which holds this up as a useful safety measure and determining which is correct requires knowing the context you work in. Given the vanishingly tiny amount of time I've spent on debugging issues this restriction might have prevented Rust just looks very unergonomic to me, but the opposite perspective can be just as valid given the right context.
- pixel_fcker 7y ago
  I think the key difference here is that in your code you’re saying you “know” that it’s safe to write to these certain sections of the array from different threads. That’s an invariant that‘s held in your memory (or in a comment maybe). The rust equivalent is doing the exact same thing but requires you to formalise that invariant in your code by using one of the methods defined above. I can see how initially this looks like an extra hoop to jump through but after using it for a while I’ve found the opposite is true: because those invariants are checked by the compiler it’s one less thing I have to keep in my head and I can concentrate on the real problem.
  - safercplusplus 7y ago
    And also one less thing to transfer to the heads of anyone else that might need/want to understand the code. (Often the author him or herself at some point in the future, right?) Though equivalent facilities are available in C++ [1][2] (and can now/soon be enforced[3]). [1] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master/README.md#tasyncrasectionsplitter https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [2] https://github.com/duneroadrunner/SaferCPlusPlus/blob/master/README.md#scope-threads https://github.com/duneroadrunner/SaferCPlusPlus/blob/master... [3] https://github.com/duneroadrunner/scpptool https://github.com/duneroadrunner/scpptool