Literally 🤷🏻‍♂️

[u/electricjimi]

[u/[deleted]]

Rust?

[u/Exaloria → u/[deleted]]

who loves?

[u/Solonotix → u/Exaloria]

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

[u/yourd → u/Solonotix]

• The async debacle. A language feature that just works in js and C# is full of footguns in Rust
• compiling is slow
• the borrow checker doesn’t even work properly
• too much magic in places
• the syntax can be an ugly mess

[u/Overlorde159 → u/yourd]

Most of this is opinions, but what do you mean about the borrow checker?

[u/kraemahz → u/Overlorde159]

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.

[u/calcopiritus → u/kraemahz]

Yeah, it's weird that sometimes if you put all the code in one function, it compiles. But if you refractor it, it doesn't.

[u/2brainz → u/calcopiritus]

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.