Read on Twitter
Musings about developing in Rust:
When people start in Rust, they often get into 'fights' with the borrow checker. This can be a source of much frustration, especially for experienced devs who try to use patterns they know from other languages which give them lots of headaches.
When people start in Rust, they often get into 'fights' with the borrow checker. This can be a source of much frustration, especially for experienced devs who try to use patterns they know from other languages which give them lots of headaches.
This can give off the impression that in order to dev in Rust you need to do overly complex lifetime annotation and/or runtime borrow checking in order to satisfy borrowck.
However, as you get more experienced with Rust, you start to notice that this is not really true at all.
However, as you get more experienced with Rust, you start to notice that this is not really true at all.
Instead, you realize is that getting into 'fights' with the borrow checker is actually a *symptom* of a deeper problem of ambiguous data ownership in your program.
This is really interesting because it can give you an early forecast of deeper issues on the horizon!
This is really interesting because it can give you an early forecast of deeper issues on the horizon!
If borrowck is making your life hard, even early on in a project, it's a pretty good sign that *you need to reevaluate data ownership in your code*.
I think this is something that experienced Rust devs sort of do without even realizing it; they've discovered over time that >
I think this is something that experienced Rust devs sort of do without even realizing it; they've discovered over time that >
fighting borrowck almost never leads to good things, and so they sort of instinctively change things around when they see the first signs of trouble.
And, I think it's really interesting to get this emergent behavior: borrowck was never really designed to be prescriptive, afaik!
And, I think it's really interesting to get this emergent behavior: borrowck was never really designed to be prescriptive, afaik!
Just to clarify what I meant by this last point:
borrowck is designed to check the *correctness* of your code *implementation*, but it was never really meant to be able to tell you whether your overall program *design*/structure is good or not....
borrowck is designed to check the *correctness* of your code *implementation*, but it was never really meant to be able to tell you whether your overall program *design*/structure is good or not....
And I think it's really interesting that, in practice, the first thing seems to in some way imply the second as well.
An interesting addendum to this, as discussed here https://twitter.com/aboodman/status/1306044416021245952?s=20
oftentimes, the way borrowck pushes you is not the *only* correct way to do things! perhaps your original idea was actually valid, and it just couldn't be verified b/c borrowck is not smart enough...
oftentimes, the way borrowck pushes you is not the *only* correct way to do things! perhaps your original idea was actually valid, and it just couldn't be verified b/c borrowck is not smart enough...
Interestingly, the fact that borrowck isn't as smart as a human can be is often a good thing! It means that once you come up with a way to express what you want to do in a way that borrowck understands, it'll be simple enough that a human can more easily verify & work on it too!
