How to Avoid Fighting Rust Borrow Checker

52 points by ucirello

bitshift

Deferred mutation is not "just a workaround for borrow checker". Treating mutation as data also has other benefits:

The author goes on to mention several bits of added functionality that are easier with mutations-as-data, such as adding logging or parallelism. Which is true, but what it eliminates is just as important: certain classes of bugs.

I play an old DOS game that has various weird bugs whenever a creature dies: e.g., kill this monster and an unrelated segment of wall shifts forward. The reason is because there's an array of all the objects on screen, and that array is mutated concurrently with the objects running their scripts (such as one object killing another), causing array indexes to get mixed up for a frame. No fighting the borrow checker in Turbo Pascal! But a borrow checker would have encouraged a cleaner design, such as setting an is_deleted boolean somewhere and deleting the array entries only after iteration had finished.

BenjaminRi

Yes, see also this related discussion about this topic: https://lobste.rs/s/k1caa2/rust_s_borrow_checker_not_just_nuisance

wrs

This is great! I wish I had seen this closer to the start of my Rust journey.

The Traps to Developers post is also great, a lot of hard-won knowledge in a small space.

jasonjmcghee

I don't think I use the command queue pattern enough. It really is great for observability. I imagine there's merge / coalesce / replace optimizations that could be done in certain situations as well, so you end up spending less total compute... Also could help with hot path stuff by colocating writes.

What are some reasons why command queue is bad that come to mind for people?

arxanas
I'm quite a fan of event sourcing patterns like the command queue.

The main problem I encounter is poor provenance tracking:
- It's true that this pattern makes it easier to observe identify "incorrect" commands; but it's oftentimes equivalent to structured logging or other means.
- Current languages/environments are not good at tracking the source of a piece of data. By reifying 'mutations' as 'commands', it becomes too easy to have a command in hand and wonder "this is wrong; where did it come from?"
- In contrast, in-place mutations can allow you to intercept events as they happen via debuggers/stack traces/etc.
  - This isn't fundamental; you can certainly attach provenance information manually (even including a stack trace, depending on your runtime and the performance costs).
  - But the fact is that we have a lot of debugging tools already built around the "stack trace" paradigm.
Another problem is that direct mutation can often provide you with a natural backpressure mechanism.
- If every thread is physically busy doing writes, then they're too busy to do reads, and it's a lot harder to accidentally queue up more work than you can handle.
  - This is not really by "design"; just a happy accident, in most cases.
  - Granted, you can still run into problems if you're scheduling many app-level tasks onto fewer physical cores.
- Whereas some environments might encourage, or at least not discourage, users from creating unbounded queues.
  - Example: If you just use a mutex-wrapped list in your environment of choice, then you might set yourself up for this in the future.
- sunshowers
  
  Definitely put reasons for each operaion in whenever I use this pattern (which is quite often). Reify Every If Statement.
koala

Added it as the second article in a list whose first article is The Mediocre Programmer's Guide to Rust.
nrposner

The article could do with an editing pass for phrasing and grammar, but excellent otherwise. I’m learning a lot!
- wofo
  
  For anyone out there who'd like to proofread their documents but finds it too cumbersome to actually ask someone else, I think this is an excellent use case for LLMs. Not everything they suggest makes sense (surprise, surprise), but I usually let an LLM proofread my blog posts and feel like it helps with the last bit of polish.
  
  You do need to have your own ideas about writing, though. For instance, I am fairly critical of LLM feedback and only accept minor tweaks. I'll never let an LLM write for me (e.g. rewrite whole sentences), I prefer my own voice.
  - freddyb
    
    In this case, a simple spell checker would have done wonders. Not to throw shade at the author. Loved the article, helped me rethink my tiny rust programs
- yshui
  
  Ultimately this is because Rust doesn't have the concept of a partial borrow, and I do feel that would a beneficial thing to have. People has put thoughts into this, but nothing has come out so far.
- orib
  
  Comment removed by author
- rtpg
  
  I've witnessed a lot of open source projects use cloning as their way out of the mess, but it ends up backfiring in some cases, with huge objects getting cloned despite usage of the objects themselves being treated as immutable.
  
  It does feel weird that just passing around IDs into a memory store feels like the way to go in so many cases. We're not exactly at NullPointerException territory because when reading values out we still are confronted with nullness checks but it all feels a bit silly.
  
  Perhaps we just need to get better about lifetimes in general. I think the Ruffle codebase has some decent lifetime strategies for example, IIRC using the arena's lifetime all over the place.