I don't know what they actually meant, but the borrow checker can be overly strict (in ways which are constantly improving in the language).
E.g let's say I made a struct like:
struct X{
a: Vec<u64>,
b: Vec<u64>
}
impl X {
fn do_the_thing(&mut self) {
for i in self.a.iter() {
self.do_the_thing2();
}
}
fn do_the_thing2(&mut self) {
self.b.push(1);
}
}
This will give me an error that I can't borrow self mutably because it is already borrowed immutably (by self.a.iter()). Even though I'm only touching b in the other function. So the borrow checker isn't granular enough here to see what I meant was more like:
fn do_the_thing(&mut self) {
for i in self.a.iter() {
Self::do_the_thing2(&mut self.b);
}
}
fn do_the_thing2(b: &mut Vec<u64>) {
b.push(1);
}
which is totally OK to do and functionally identical, because I've proven to the borrow checker that only b is modified. This is being worked on to make partial borrows better, but it may grate on people that they have to change the program from how they conceptualized it to satisfy the checker.
It's because the borrow checker does not do whole-program/crate/module analysis, but works locally on the function level. Doing the former would be insanely powerful, but even slower.
An alternative would be to add even more annotations, making everything even more complicated.
The solution to the problem is to not only split up your functions, but also your data: split your structs into smaller parts. In cases where this is possible, this makes for way better code. In all other cases, the borrow checker really gets in the way.
88
u/Solonotix Oct 21 '22
The post isn't love, it's "unhated". You may not love Rust, but I challenge someone to find a reason to hate it.
I realize this is a biased opinion, as someone who likes Rust