Rust dev, I enjoy reading and playing games, I also usually like to spend time with friends.

You can reach me on mastodon @sukhmel@mastodon.online or telegram @sukhmel@tg

  • 0 Posts
  • 63 Comments
Joined 1 year ago
cake
Cake day: July 3rd, 2023

help-circle




  • I think, the idea was along the lines of “because C++ was not memory-safe, and it has to stay compatible with how it was, there are still a lot of ways to not write memory-safely”

    This makes sense, there are memory-safely features available but there are a lot of programmers that will never willingly use that features, because the olden ways are surely better

    Other than that, I agree, when you’re paid to fix an unfixable problem you will probably claim something like that and advocate for your solution being the only one that solves this


  • I see now, that you were misunderstood in some parts.

    even if I got reported a really weird bug related to UB, I should (I am not experienced enough to make a claim) be able to know it’s UB since the game’s gonna crash when I try to recreate the bug in Debug.

    This may be problematic for several reasons: it may be hard to reproduce, the more complicated the state, the harder; bug may rely on some race condition that may be much rarer in Debug because of speed difference; UB is notorious for causing things that should (seemingly) never happen, like returning from infinite loops, proving false statements true, and such, so it may be hard to understand what at all happened and why.

    Regarding optimisations, it might still be better to try to profile the code (I will be honest, I don’t do that until the moment when I can’t go further without optimisation, and I haven’t reached that with Rust) and see what are the real hot spots that require optimisations. I hope that someday you will be able to upgrade your machine, and hope that your game will be a good example of something that really runs anywhere


  • I just wanted to advice you against thinking that if there’s something in all cases you’ve tried, there’s something every time. When you put something in an optional and then unwrap, it’s okay because you can see that the value is there, but even then there are usually better ways to express that. When you expect that since you’ve run the code thousands of times and it didn’t break [in a way that you would notice, e.g. panic in another thread will only affect that thread] means that everything is fine, you may get weird bugs seemingly out of nowhere and will also need to test much more than strictly necessary.

    Regarding the borrow checker, it has limitations and there are improvements that I hope will some day find way into upstream, but most of the time it may be better to change the code flow to allow borrow checker to help with bugs, instead of throwing it away completely. The same goes for unsafe, as in most cases it’s better to not uphold invariants manually.