7 ms·

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'l

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

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...).