10 ms·

"Crappy pessimistic heuristics" Are you talking about the borrow checker from half a decade ago? [0] Have you used the language since then? This is FUD -- it's

by ohazi 9y ago

"Crappy pessimistic heuristics" Are you talking about the borrow checker from half a decade ago? [0] Have you used the language since then? This is FUD -- it's really not hard to get code past the borrow checker anymore. Maybe every thousand lines or so you'll need to add a block or pull a temporary variable out of a one-liner, but the compiler basically tells you exactly what to do when something like that is relevant. [0] https://pcwalton.github.io/blog/2013/01/21/the-new-borrow-check-in-a-nutshell/ https://pcwalton.github.io/blog/2013/01/21/the-new-borrow-ch...

pjmlp 9y ago
Try to use the borrow checker of this decade to write callbacks in GUI frameworks, without polluting the code with Rc and RefCell, even though it is obvious there is only one path to the data being used.
- Rusky 9y ago
  Callbacks by definition create multiple paths to the data. (You can also often get away with Cell rather than RefCell.)
  - pjmlp 9y ago
    > Callbacks by definition create multiple paths to the data. How come, when you have a struct method, accessing field members only visible to that specific method. Something that is very easy to do with moving in lambda contexts in C++.
    - pmarcelll 9y ago
      The quoted sentence is not true, but most practical callbacks will create multiple paths to objects via borrows. Or you can move your structs into closures (like in C++). But I think what you originally wrote (using callbacks without Rc/RefCell) is fundamentally hard. You have to guarantee somehow that the struct is still alive when you access it though the borrow in the callback, otherwise you have a memory safety problem.
      - pjmlp 9y ago
        The situation I was having issues is explicitly acknowledged by the NLL RFC as being an issue. It is related to closure desugaring. https://github.com/nikomatsakis/nll-rfc/blob/master/0000-nonlexical-lifetimes.md https://github.com/nikomatsakis/nll-rfc/blob/master/0000-non...
    - Rusky 9y ago
      Because the closure itself contains a reference either to the struct or to its fields. That's the second path, and it can be invalidated by the first path either a) freeing the struct or b) changing its "shape" in memory (resizing a `Vec`, changing enum variants, etc.) You can alternatively move the struct or its fields into the closure, but then you lose the first path. I know you're not doing that because if you were you wouldn't be having lifetime problems (and you wouldn't be able to share the state across event handlers, so it's not a great solution anyway).
onli 9y ago
Oh, I'd love if that were true. But in my limited experience with Rust it was still the borrow checker that absolutely made writing in the language hard. That was in 2017. My mental model of what should be safe was not at all the model the borrow checker had. And I really read the documentation about that part of the language. I guess a confirmation that there were problems there is that they tried to improve the borrow checker in the releases after that.
- majewsky 9y ago
  I started working with Rust last month, and wrote about 2000 LOC since then. While I had my fair share of errors coming from the borrow checker, I've always found its complaints to be valid and easily resolved. Except for that one time where I tried to shuffle data between different threads and shouted at the borrow checker for two hours, until I realized that the borrow checker was actually right and what I tried to do was literally impossible without data races.
- smaddox 9y ago
  Were you writing functions/procedures under the implicit assumption that they would be executed under a single threaded context? Because Rust does not allow this assumption without using "unsafe". I've run into this before, and it can be a bit irritating, but if there's even a small chance you'll later want to execute the code in a multithreaded context, it will more than pay for the inconvenience. And if you're sure you won't, then you can just throw the data into an UnsafeCell and call it a day.
  - steveklabnik 9y ago
    It's not even inherently about multi-threading https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ https://manishearth.github.io/blog/2015/05/17/the-problem-wi...

by ohazi 9y ago

pjmlp 9y ago

Try to use the borrow checker of this decade to write callbacks in GUI frameworks, without polluting the code with Rc and RefCell, even though it is obvious there is only one path to the data being used.

Rusky 9y ago
Callbacks by definition create multiple paths to the data. (You can also often get away with Cell rather than RefCell.)
- pjmlp 9y ago
  > Callbacks by definition create multiple paths to the data. How come, when you have a struct method, accessing field members only visible to that specific method. Something that is very easy to do with moving in lambda contexts in C++.
  - pmarcelll 9y ago
    The quoted sentence is not true, but most practical callbacks will create multiple paths to objects via borrows. Or you can move your structs into closures (like in C++). But I think what you originally wrote (using callbacks without Rc/RefCell) is fundamentally hard. You have to guarantee somehow that the struct is still alive when you access it though the borrow in the callback, otherwise you have a memory safety problem.
    - pjmlp 9y ago
      The situation I was having issues is explicitly acknowledged by the NLL RFC as being an issue. It is related to closure desugaring. https://github.com/nikomatsakis/nll-rfc/blob/master/0000-nonlexical-lifetimes.md https://github.com/nikomatsakis/nll-rfc/blob/master/0000-non...
  - Rusky 9y ago
    Because the closure itself contains a reference either to the struct or to its fields. That's the second path, and it can be invalidated by the first path either a) freeing the struct or b) changing its "shape" in memory (resizing a `Vec`, changing enum variants, etc.) You can alternatively move the struct or its fields into the closure, but then you lose the first path. I know you're not doing that because if you were you wouldn't be having lifetime problems (and you wouldn't be able to share the state across event handlers, so it's not a great solution anyway).

onli 9y ago

Oh, I'd love if that were true. But in my limited experience with Rust it was still the borrow checker that absolutely made writing in the language hard. That was in 2017. My mental model of what should be safe was not at all the model the borrow checker had. And I really read the documentation about that part of the language. I guess a confirmation that there were problems there is that they tried to improve the borrow checker in the releases after that.

majewsky 9y ago
I started working with Rust last month, and wrote about 2000 LOC since then. While I had my fair share of errors coming from the borrow checker, I've always found its complaints to be valid and easily resolved. Except for that one time where I tried to shuffle data between different threads and shouted at the borrow checker for two hours, until I realized that the borrow checker was actually right and what I tried to do was literally impossible without data races.
smaddox 9y ago
Were you writing functions/procedures under the implicit assumption that they would be executed under a single threaded context? Because Rust does not allow this assumption without using "unsafe". I've run into this before, and it can be a bit irritating, but if there's even a small chance you'll later want to execute the code in a multithreaded context, it will more than pay for the inconvenience. And if you're sure you won't, then you can just throw the data into an UnsafeCell and call it a day.
- steveklabnik 9y ago
  It's not even inherently about multi-threading https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ https://manishearth.github.io/blog/2015/05/17/the-problem-wi...