3 ms·

> I would often write huge refactorings thinking that they would be a solution to a borrow checker error, just to get another one at the end of the refactoring.

• winrid 4y ago
  This was my experience too. Although, it's less of an issue now. It was definitely frustrating, though.
• pornel 4y ago
  Proficiency in Rust requires learning what won't work, rather than trying various things until they compile. Borrow checking is a set of rules to design for, rather than an oracle to test against. It does take time and effort to really internalize these rules. But eventually you should be able to have a mental model of how ownership and borrowing work; consider what owns the data, if it can be borrowed within statically known scopes, will it need to mix sharing and mutation, and then apply Rust-specific types and design patterns to match. Conversely, there are things that you just can't do, like using temporary references for parent-child relationships. Knowing this will save you time from even trying. Perhaps learning materials need to be more explicit about it. For example, I suspect lots of people are discovering the limitation of self-referential structs the hard way.
  • jbrr25 4y ago
    Count me in. I was doing the advent of code and tried to solve one problem with a tree that had parent references. Much thinking was done trying to please the borrow checker with no results, add some inner mutability and I got stucked. I agree that it should be more prominent in some place. I got most of my info about that in StackOverflow and I tried using a hashmap to simulate the tree structure, but I don't think I finished that one.