Comment
nh wrote on 04 January 2025
This is a perfect sample of what is wrong with using Rust everywhere.
Every decent C++ programmer would make this loop without bugs/issues that Rust supposedly prevents.
With Rust, you needed to solve nontrivial code structure problems caused by Rust itself.
If you have no issue with creating a temporary array ('a minor performance penalty' you say), maybe C# should have been the language of your choice...
This is just silly...
reply
This is a perfect sample of what is wrong with using Rust everywhere.
Every decent C++ programmer would make this loop without bugs/issues that Rust supposedly prevents.
With Rust, you needed to solve nontrivial code structure problems caused by Rust itself.
If you have no issue with creating a temporary array ('a minor performance penalty' you say), maybe C# should have been the language of your choice...
This is just silly...
reply
Post comment
Replies
bux wrote on 10 January 2025
> Every decent C++ programmer would make this loop without bugs/issues that Rust supposedly prevents
It's precisely because we want to think that, that the software world is so buggy.
reply
> Every decent C++ programmer would make this loop without bugs/issues that Rust supposedly prevents
It's precisely because we want to think that, that the software world is so buggy.
reply
Benjamin (admin) wrote on 05 January 2025
I believe you misunderstood the blog post. The point is precisely that if I were using a language like C++, I would have opted for the solution that uses nested loops, which would have resulted in unfair gameplay when players try to land fatal blows on each other in the exact same frame.
To address the 'minor performance penalty': the vector can be allocated once and then reused. Since the maximum number of players is low (8-12), a fixed-size array on the stack could be used, making the solution fully allocation-free. I didn't mention this because it's an irrelevant implementation detail and I wanted to keep the examples as simple as possible.
reply
I believe you misunderstood the blog post. The point is precisely that if I were using a language like C++, I would have opted for the solution that uses nested loops, which would have resulted in unfair gameplay when players try to land fatal blows on each other in the exact same frame.
To address the 'minor performance penalty': the vector can be allocated once and then reused. Since the maximum number of players is low (8-12), a fixed-size array on the stack could be used, making the solution fully allocation-free. I didn't mention this because it's an irrelevant implementation detail and I wanted to keep the examples as simple as possible.
reply
Empty_String wrote on 15 January 2025
tbf, had you used indices from the very beginning - you'd hit the logic bug in Rust as well
and had you used iterators in C++, you would not hit any memory problems that borrow checker false-alarms you about
what you actually demonstrated is that borrow checker _made you change program behaviour_ and you didn't even notice it
"removal" of logic bug could have easily been "adding" of such - and kinda points to developer experience still being important, no matter what borrow checker cult might suggest
reply
tbf, had you used indices from the very beginning - you'd hit the logic bug in Rust as well
and had you used iterators in C++, you would not hit any memory problems that borrow checker false-alarms you about
what you actually demonstrated is that borrow checker _made you change program behaviour_ and you didn't even notice it
"removal" of logic bug could have easily been "adding" of such - and kinda points to developer experience still being important, no matter what borrow checker cult might suggest
reply