8 ms·

The borrow checker drawbacks was actually one of my biggest pet peeves with Rust. If you guys can solve that problem in a meaningful way it'll go a long way to

by braveo 10y ago

The borrow checker drawbacks was actually one of my biggest pet peeves with Rust. If you guys can solve that problem in a meaningful way it'll go a long way towards making me a lot more positive about using Rust. As it was, I felt as though I were manipulating a child in order to get it to do what I wanted.

Manishearth 10y ago
FWIW a lot of the issues that newcomers come across are just due to lack of familiarity. The feeling of manipulating a child is common initially, but soon you'll learn how Rust expects you to design your code, and you'll be able to write code that passes the borrow checker without much issue. This is true when learning most languages; it takes some time to write code idiomatically, and till then you'll be stumbling over many things. But yeah, we should improve this.
- madez 10y ago
  The learning curve of a program is relevant. Even if it just takes a weekend of fiddling around with Rust to learn how to satisfy it, it will hinder adoption.
  - Manishearth 10y ago
    Of course. And we're always looking to improve that. Just pointing out that this isn't as major a problem when actually using Rust once you've picked it up.
- vvanders 10y ago
  I'd concur, in fact I don't know if I'd like to see the borrow checker get more complex because then it becomes harder to keep a mental model in your head of what it's doing. I found once I grasped the model that the borrow checker uses that I rarely fight it and instead find it catching many things that I miss.
  - steveklabnik 10y ago
    Yes, I've said this as well. Non-lexical lifetimes will make the borrow checker more complex; but if it tends to work closer to the way that you intuit things, as a developer, it will _feel_ simpler. Right now, the rules are very simple to explain. But that means your code gets a little more complex at times.
    - braveo 10y ago
      > Right now, the rules are very simple to explain. But that means your code gets a little more complex at times. And more awkward in places due to convincing the checker that what you're doing is ok.
    - Manishearth 10y ago
      I think a good example of this is how value categories work in C++ (even pre-move-semantics). It's initially quite intuitive and makes sense. But as you use the language more you start questioning why it doesn't make sense and you eventually have to learn how rvalues work.
- braveo 10y ago
  It has nothing to do with familiarity, it's due to the checker not being able to identify safe usages that are obviously safe to a human. Atleast steveklabnik had the good sense to acknowledge the issue rather than blame it on the developer.
  - Manishearth 10y ago
    I'm not blaming it on the developer. I acknowledge that we should improve here. I'm merely pointing out that this is not always an issue when programming in Rust, just mostly for newcomers, which means that if you're willing to bear with it for a while whilst learning it won't be a problem later. This isn't an ideal situation and is one we should fix. But it's not as bad as a problem that plagues you whenever you are writing Rust code.
    - braveo 10y ago
      It's not a problem in that you can make your code more awkward to work around it, but it's still a problem.
      - Manishearth 10y ago
        No, you misunderstand what I'm saying, I'm saying that a lot of these issues don't crop up in the first place -- because you've structured your code a different way -- not an awkward way, just different (more idiomatic) -- once you have some experience with Rust. Some of these problems persist as awkwardness in even idiomatic code. Most go away. I write Rust code every day, and I've seen or written borrowck-induced awkward Rust code maybe twice this month. All of this is not to say that it isn't a problem we should be fixing -- it is and we are. But it's less of an annoyance in everyday Rust programming than one initially gets the impression it will be.
        braveo 10y ago
        > I write Rust code every day, and I've seen or written borrowck-induced awkward Rust code maybe twice this month. Which is exactly what I was describing, why are you continuing to argue against the point?
- weberc2 10y ago
  Usually when other languages expect something of their users, its for good reason--there's some tangible benefit in exchange. When they don't, we call it a wart and count it against the language. This seems like a wart.
  - Manishearth 10y ago
    It's a mixture of the two. Some of the borrowck errors are due to warts which we hope to eventually fix. Others are due to not-immediately-obvious issues with code. One of the most common borrowck complaints I've seen is about the fact that you can't have mutable and immutable aliases operating simultaneously, even if you don't have threads involved. There's a reason behind that (http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...).
madez 10y ago
I also think this is an issue for Rust. The borrow checker needs to understand more, safe programs. Some are trivially safe but the borrow checker can't verify that. That is a problem. I don't even think the borrow checker needs to become super clever, but it is too rudimentary right now.
- steveklabnik 10y ago
  Specifics here would be very useful; sometimes you _think_ something is safe, but it's not, because you forgot something the compiler didn't. Take http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit... for example...
  - madez 10y ago
    How about the example given below by Manish? The following program will never fail. fn main() { let mut x = 0; let y = &x; println!("{}", y); x += 1; println!("{}", x); } It still doesn't pass the borrow checker.
    - steveklabnik 10y ago
      I mean, yes, I'm not saying that there aren't safe programs that the borrow checker can't know about. This is an inherent aspect of how safety works; for soundness reasons, you want to be conservative. What I do mean is, many times we have people drop by IRC and say "the borrow checker is dumb, I want to do X, and it won't let me" and the reply is something like "have you considered threading" and they go "ohhhhh I see." There was a good quote of the week about this at some point, but I can't find it right now. I don't happen to run into patterns like the above code in real Rust code, personally. That doesn't mean that they don't happen, but I'm interested in _real world_ cases where this becomes an issue. We've got a bunch of them, which is why we're pursuing non-lexical lifetimes, but it seems like for many, this is a _constant_ struggle, and I run into a NLL situation maybe once every two months. Figuring out that disconnect is very interesting to me. It matters because I'm going to be responsible for teaching it, so real examples are way better than contrived ones. Moving that focus is the point of my current re-write of these docs :)
lemming 10y ago
If only manipulating my child were as easy as solving borrow checker problems. At least the borrow checker tells you what you're doing wrong.

by braveo 10y ago

Manishearth 10y ago

FWIW a lot of the issues that newcomers come across are just due to lack of familiarity. The feeling of manipulating a child is common initially, but soon you'll learn how Rust expects you to design your code, and you'll be able to write code that passes the borrow checker without much issue. This is true when learning most languages; it takes some time to write code idiomatically, and till then you'll be stumbling over many things. But yeah, we should improve this.

madez 10y ago
The learning curve of a program is relevant. Even if it just takes a weekend of fiddling around with Rust to learn how to satisfy it, it will hinder adoption.
- Manishearth 10y ago
  Of course. And we're always looking to improve that. Just pointing out that this isn't as major a problem when actually using Rust once you've picked it up.
vvanders 10y ago
I'd concur, in fact I don't know if I'd like to see the borrow checker get more complex because then it becomes harder to keep a mental model in your head of what it's doing. I found once I grasped the model that the borrow checker uses that I rarely fight it and instead find it catching many things that I miss.
- steveklabnik 10y ago
  Yes, I've said this as well. Non-lexical lifetimes will make the borrow checker more complex; but if it tends to work closer to the way that you intuit things, as a developer, it will _feel_ simpler. Right now, the rules are very simple to explain. But that means your code gets a little more complex at times.
  - braveo 10y ago
    > Right now, the rules are very simple to explain. But that means your code gets a little more complex at times. And more awkward in places due to convincing the checker that what you're doing is ok.
  - Manishearth 10y ago
    I think a good example of this is how value categories work in C++ (even pre-move-semantics). It's initially quite intuitive and makes sense. But as you use the language more you start questioning why it doesn't make sense and you eventually have to learn how rvalues work.
braveo 10y ago
It has nothing to do with familiarity, it's due to the checker not being able to identify safe usages that are obviously safe to a human. Atleast steveklabnik had the good sense to acknowledge the issue rather than blame it on the developer.
- Manishearth 10y ago
  I'm not blaming it on the developer. I acknowledge that we should improve here. I'm merely pointing out that this is not always an issue when programming in Rust, just mostly for newcomers, which means that if you're willing to bear with it for a while whilst learning it won't be a problem later. This isn't an ideal situation and is one we should fix. But it's not as bad as a problem that plagues you whenever you are writing Rust code.
  - braveo 10y ago
    It's not a problem in that you can make your code more awkward to work around it, but it's still a problem.
    - Manishearth 10y ago
      No, you misunderstand what I'm saying, I'm saying that a lot of these issues don't crop up in the first place -- because you've structured your code a different way -- not an awkward way, just different (more idiomatic) -- once you have some experience with Rust. Some of these problems persist as awkwardness in even idiomatic code. Most go away. I write Rust code every day, and I've seen or written borrowck-induced awkward Rust code maybe twice this month. All of this is not to say that it isn't a problem we should be fixing -- it is and we are. But it's less of an annoyance in everyday Rust programming than one initially gets the impression it will be.
      - braveo 10y ago
        > I write Rust code every day, and I've seen or written borrowck-induced awkward Rust code maybe twice this month. Which is exactly what I was describing, why are you continuing to argue against the point?
weberc2 10y ago
Usually when other languages expect something of their users, its for good reason--there's some tangible benefit in exchange. When they don't, we call it a wart and count it against the language. This seems like a wart.
- Manishearth 10y ago
  It's a mixture of the two. Some of the borrowck errors are due to warts which we hope to eventually fix. Others are due to not-immediately-obvious issues with code. One of the most common borrowck complaints I've seen is about the fact that you can't have mutable and immutable aliases operating simultaneously, even if you don't have threads involved. There's a reason behind that (http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...).

madez 10y ago

I also think this is an issue for Rust. The borrow checker needs to understand more, safe programs. Some are trivially safe but the borrow checker can't verify that. That is a problem. I don't even think the borrow checker needs to become super clever, but it is too rudimentary right now.

steveklabnik 10y ago
Specifics here would be very useful; sometimes you _think_ something is safe, but it's not, because you forgot something the compiler didn't. Take http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit... for example...
- madez 10y ago
  How about the example given below by Manish? The following program will never fail. fn main() { let mut x = 0; let y = &x; println!("{}", y); x += 1; println!("{}", x); } It still doesn't pass the borrow checker.
  - steveklabnik 10y ago
    I mean, yes, I'm not saying that there aren't safe programs that the borrow checker can't know about. This is an inherent aspect of how safety works; for soundness reasons, you want to be conservative. What I do mean is, many times we have people drop by IRC and say "the borrow checker is dumb, I want to do X, and it won't let me" and the reply is something like "have you considered threading" and they go "ohhhhh I see." There was a good quote of the week about this at some point, but I can't find it right now. I don't happen to run into patterns like the above code in real Rust code, personally. That doesn't mean that they don't happen, but I'm interested in _real world_ cases where this becomes an issue. We've got a bunch of them, which is why we're pursuing non-lexical lifetimes, but it seems like for many, this is a _constant_ struggle, and I run into a NLL situation maybe once every two months. Figuring out that disconnect is very interesting to me. It matters because I'm going to be responsible for teaching it, so real examples are way better than contrived ones. Moving that focus is the point of my current re-write of these docs :)

lemming 10y ago

If only manipulating my child were as easy as solving borrow checker problems. At least the borrow checker tells you what you're doing wrong.