←back to thread

Stop making me memorize the borrow checker

(erikmcclure.com)
177 points signa11 | 3 comments | 16 Nov 24 23:29 UTC | HN request time: 0s | source
Show context
skp1995 ◴[17 Nov 24 00:43 UTC] No.42160949[source]▶
Rust can be hard to get right because of the borrow checker. I had a similar situation happen to me where I went about refactoring the code to make borrow checker happy ... until the last bit when things stopped compiling and I realized my approach was completely wrong (in the rust world, I had a self-reference in the structs)

Having said this, the benefits of borrow checker out weight the shortcomings. I can feel myself writing better code in other languages (I tend to think about the layout and the mutability and lifetimes upfront more now)

My rust code now is very functional, which seems to work best with lifetimes.

I would love to know more about the authors pain, I do hope rustc gets better at lifetime compilation errors cause some of them can be very very gnarly.

replies(2): >>42160986 #>>42162509 #
1. estebank ◴[17 Nov 24 00:48 UTC] No.42160986[source]▶
> I do hope rustc gets better at lifetime compilation errors cause some of them can be very very gnarly.

When this happens, file tickets! We do our best to improve diagnostics over time, but the best improvements have been reactive, by fixing a case that we never encountered but our users did.

replies(1): >>42161031 #
2. skp1995 ◴[17 Nov 24 00:59 UTC] No.42161031[source]▶
will keep that in mind going forward! The most recent ones which I have been hitting are around "higher-ranked lifetime error"

I know my way around this now, which is to literally binary search over the timeline of my edits (commenting out code and then reintroducing it) to see what causes the compiler to trip over (there might be better ways to debug this, and I am all ears)

Most of the times this error is several layers deep in my application so even tho I want to ticket it up, not being able to create a minimal repo for anyone to iterate against feels like a bit of wasted energy on all sides, do let me know if I should change this way of thinking and I can promise myself to start being more proactive.

replies(1): >>42161143 #
3. estebank ◴[17 Nov 24 01:18 UTC] No.42161143[source]▶
If it's public code, a link to a branch with the issue can still be useful. Looking at the compiler internals you can get a better sense on how to minimize the issue. That being said, not having a minimised repro lowers the chance of it getting addressed quickly.

Even if you have already figured out how to deal with it, your future colleagues might not, and by improving the diagnostic you would also be getting that time manually commenting code back.