11 ms·

I never tried zig but I want to address something the article wrote > People struggle with Rust for a number of reasons ... the borrow checker! The borrow che

I never tried zig but I want to address something the article wrote > People struggle with Rust for a number of reasons ... the borrow checker! The borrow checker was the easiest thing for me to learn and the only thing I liked about rust. Except it's broken. I have to constantly reborrow after calling a constant function. The reason I actually bailed on rust is because it's a worse C++ (compiles slower, executes slower, isn't compatible with C's __thread etc etc), it's a worse webserver (I still use PHP and C#), it's worse for database heavy code, it's not very good for one offs (C# and python are better), it basically cost too much to switch for the broken borrow checker Also the article at the end doesn't make it clear what he thinks. Usually I read the start and end to see if I'm interested in the topic and I'm not sure if this article is in secret a rant

swsieber 4y ago
The borrow checker has been through a couple revisions now, and it's got better each time.
- ArrayBoundCheck 4y ago
  I tried it again in 2021 and it still failed to deal with constant functions. Here's it again in 2022 https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e5bcaac465031fdc12323b2e4a8da58a https://play.rust-lang.org/?version=stable&mode=debug&editio...
  - magicalhippo 4y ago
    I don't know any rust but the error description[1] only talks about borrowing mutable from an immutable, which to me seems like an obvious error. However the compiler complains about the reverse condition. Again, I don't know any rust, so it's not clear why that's an error. So is it a documentation bug or a compiler bug? [1]: https://doc.rust-lang.org/stable/error-index.html#E0502 https://doc.rust-lang.org/stable/error-index.html#E0502
    - ArrayBoundCheck 4y ago
      I only understand it because I learned how not to shoot myself in the foot with the canon that is C++ I'll sum up "container invalidation". In C or C++ if you append an array you may cause the array to grow which means it might have a different pointer. You basically can't take an address of an array you're planning to grow. All containers are like that except list I think which I never use In rust, it's roughly the same idea. The problem is I borrowed something from vec (you can think of it as taking a reference or creating a pointer). I then call a function that is const (you can see here it's &self and not &mut self https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#1911 https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#1911). But that invalidates the borrow like push_back/resize/reserve and such in C++. Which is absolutely ridiculous because it's doesn't modify anything. It makes me so mad because even the one thing I like about rust is annoying to use. Using an annoying checker, slower compiler, harder to optimize language is too much. I don't shoot myself in the foot in C++ so I'm unable to get a win in rust. For me using rust is more pain than practical
      - pkolaczk 4y ago
        Can you share any compiler benchmarks showing Rust compiles slower than C++? I can see something totally opposite in my projects - particularly recompiling after a change is very quick. And cargo check often runs in less than 1s. I never got such quick incremental recompile times in any of my earlier C++ projects, particularly when using templated or header heavy libraries like STL ;) As for the borrow checker thing, it is not broken but it's simply a limitation. In a strictly statically checked it is usually possible to run into a situation of a valid program that gets rejected by the compiler. Here this limitation comes from the compiler following a pretty simple rule - only one reference is allowed if it is mutable. This simple rule is what makes many of Rust safety guarantees possible, and I guess relaxing it conditionally might be very tricky. NLLs have already made it a bit nicer recently, do maybe it is possible to improve it further.
        masklinn 4y ago
        > As for the borrow checker thing, it is not broken but it's simply a limitation. Limitations are when the borrow checker is not smart enough to understand things like sub-scope borrows (fixed by NLL) or the interaction of mutable borrows and loops (which hopefully will eventually be fixed by Polonius aka NLLv2). But here they want to acquire a shared reference to an object with an outstanding unique reference. That is quite literally the first of only two rules references have: 1. At any given time you can have either a single unique reference or multiple shared references. 2. References must be valid.
  - chlorion 4y ago
    There is nothing broken in this example, it's functioning exactly as it's intended to. What makes you think the borrow checker is broken here? It appears like you don't really understand the rule about mutable and immutable references. Asking for the length of the vector requires an immutable reference, but you already have a mutable reference, which is explicitly not allowed by design (that's the whole point!). So, you can only have one mutable reference to something if there are no immutable references, and multiple immutable references if there are no mutable references, you can never have both immutable and mutable references to something at the same time.
    - ArrayBoundCheck 4y ago
      I'm taking a reference to the array the vec is pointing to not the vec. Rust needs to be more fine grain because it's obnoxious and C++ container invalidation is less bad https://news.ycombinator.com/item?id=32188672 https://news.ycombinator.com/item?id=32188672
    - nlitened 4y ago
      I don’t know Rust, just wondering: why is it forbidden to know a length of vector to which you hold a mutable reference? What could go wrong?
      - scoutt 4y ago
        I imagine you can have one thread modifying the vector while trying to read its length from another thread.
        ArrayBoundCheck 4y ago
        Noone should imagine that. You definitely don't want two threads accessing the same vec or array at one time. Maybe if there's a lock
        nickitolas 4y ago
        If it's read only, you can definitely want that, right? As long as the elements are Sync. And it should work (You might have a problem with the cleanup, but Arc or scoped threads should handle that). The problem is when one is a mutable reference, like in this case. AIUI you could have a single mutable reference to an element be used from another thread (For example, a scoped thread) if the elements of the Vec are Sync
  - fasterthanlime 4y ago
    This particular example is trivially restructured into a version that passes the current borrow checker: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1f5aa2489f07829d12be5da9e3bf9a6e https://play.rust-lang.org/?version=stable&mode=debug&editio... It isn't the gotcha you're looking for.
nemothekid 4y ago
>I have to constantly reborrow after calling a constant function. Not sure what you mean by this, do you have an example?
- ArrayBoundCheck 4y ago
  Not sure? I wasn't aware people didn't get this problem. Maybe its the domain I'm in. Uncomment to fix. I have to repeat myself all the time and it's obnoxious (IDK how to show code on this site but heres a link https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e5bcaac465031fdc12323b2e4a8da58a https://play.rust-lang.org/?version=stable&mode=debug&editio...)
  - nemothekid 4y ago
    Oop, I'm aware of this, it is very annoying, I think I just hit it just the other day; just had no idea what you were referring to from the description.
    - ArrayBoundCheck 4y ago
      What do other people call it? > 50% of the time people don't know what I mean until I show code

swsieber 4y ago

The borrow checker has been through a couple revisions now, and it's got better each time.

ArrayBoundCheck 4y ago
I tried it again in 2021 and it still failed to deal with constant functions. Here's it again in 2022 https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e5bcaac465031fdc12323b2e4a8da58a https://play.rust-lang.org/?version=stable&mode=debug&editio...
- magicalhippo 4y ago
  I don't know any rust but the error description[1] only talks about borrowing mutable from an immutable, which to me seems like an obvious error. However the compiler complains about the reverse condition. Again, I don't know any rust, so it's not clear why that's an error. So is it a documentation bug or a compiler bug? [1]: https://doc.rust-lang.org/stable/error-index.html#E0502 https://doc.rust-lang.org/stable/error-index.html#E0502
  - ArrayBoundCheck 4y ago
    I only understand it because I learned how not to shoot myself in the foot with the canon that is C++ I'll sum up "container invalidation". In C or C++ if you append an array you may cause the array to grow which means it might have a different pointer. You basically can't take an address of an array you're planning to grow. All containers are like that except list I think which I never use In rust, it's roughly the same idea. The problem is I borrowed something from vec (you can think of it as taking a reference or creating a pointer). I then call a function that is const (you can see here it's &self and not &mut self https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#1911 https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#1911). But that invalidates the borrow like push_back/resize/reserve and such in C++. Which is absolutely ridiculous because it's doesn't modify anything. It makes me so mad because even the one thing I like about rust is annoying to use. Using an annoying checker, slower compiler, harder to optimize language is too much. I don't shoot myself in the foot in C++ so I'm unable to get a win in rust. For me using rust is more pain than practical
    - pkolaczk 4y ago
      Can you share any compiler benchmarks showing Rust compiles slower than C++? I can see something totally opposite in my projects - particularly recompiling after a change is very quick. And cargo check often runs in less than 1s. I never got such quick incremental recompile times in any of my earlier C++ projects, particularly when using templated or header heavy libraries like STL ;) As for the borrow checker thing, it is not broken but it's simply a limitation. In a strictly statically checked it is usually possible to run into a situation of a valid program that gets rejected by the compiler. Here this limitation comes from the compiler following a pretty simple rule - only one reference is allowed if it is mutable. This simple rule is what makes many of Rust safety guarantees possible, and I guess relaxing it conditionally might be very tricky. NLLs have already made it a bit nicer recently, do maybe it is possible to improve it further.
      - masklinn 4y ago
        > As for the borrow checker thing, it is not broken but it's simply a limitation. Limitations are when the borrow checker is not smart enough to understand things like sub-scope borrows (fixed by NLL) or the interaction of mutable borrows and loops (which hopefully will eventually be fixed by Polonius aka NLLv2). But here they want to acquire a shared reference to an object with an outstanding unique reference. That is quite literally the first of only two rules references have: 1. At any given time you can have either a single unique reference or multiple shared references. 2. References must be valid.
- chlorion 4y ago
  There is nothing broken in this example, it's functioning exactly as it's intended to. What makes you think the borrow checker is broken here? It appears like you don't really understand the rule about mutable and immutable references. Asking for the length of the vector requires an immutable reference, but you already have a mutable reference, which is explicitly not allowed by design (that's the whole point!). So, you can only have one mutable reference to something if there are no immutable references, and multiple immutable references if there are no mutable references, you can never have both immutable and mutable references to something at the same time.
  - ArrayBoundCheck 4y ago
    I'm taking a reference to the array the vec is pointing to not the vec. Rust needs to be more fine grain because it's obnoxious and C++ container invalidation is less bad https://news.ycombinator.com/item?id=32188672 https://news.ycombinator.com/item?id=32188672
  - nlitened 4y ago
    I don’t know Rust, just wondering: why is it forbidden to know a length of vector to which you hold a mutable reference? What could go wrong?
    - scoutt 4y ago
      I imagine you can have one thread modifying the vector while trying to read its length from another thread.
      - ArrayBoundCheck 4y ago
        Noone should imagine that. You definitely don't want two threads accessing the same vec or array at one time. Maybe if there's a lock
        nickitolas 4y ago
        If it's read only, you can definitely want that, right? As long as the elements are Sync. And it should work (You might have a problem with the cleanup, but Arc or scoped threads should handle that). The problem is when one is a mutable reference, like in this case. AIUI you could have a single mutable reference to an element be used from another thread (For example, a scoped thread) if the elements of the Vec are Sync
- fasterthanlime 4y ago
  This particular example is trivially restructured into a version that passes the current borrow checker: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=1f5aa2489f07829d12be5da9e3bf9a6e https://play.rust-lang.org/?version=stable&mode=debug&editio... It isn't the gotcha you're looking for.

nemothekid 4y ago

>I have to constantly reborrow after calling a constant function. Not sure what you mean by this, do you have an example?

ArrayBoundCheck 4y ago
Not sure? I wasn't aware people didn't get this problem. Maybe its the domain I'm in. Uncomment to fix. I have to repeat myself all the time and it's obnoxious (IDK how to show code on this site but heres a link https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e5bcaac465031fdc12323b2e4a8da58a https://play.rust-lang.org/?version=stable&mode=debug&editio...)
- nemothekid 4y ago
  Oop, I'm aware of this, it is very annoying, I think I just hit it just the other day; just had no idea what you were referring to from the description.
  - ArrayBoundCheck 4y ago
    What do other people call it? > 50% of the time people don't know what I mean until I show code