4 ms·

Personally I am not convinced Pin is a good idea as it works now. Not because of this soundness bug but because it is too hard to understand. Just look at how m

by jeltz 7y ago

Personally I am not convinced Pin is a good idea as it works now. Not because of this soundness bug but because it is too hard to understand. Just look at how much explanation is required in the manual and how large the code examples are. https://doc.rust-lang.org/beta/std/pin/index.html https://doc.rust-lang.org/beta/std/pin/index.html

kibwen 7y ago
Agreed that `Pin` is imposing by dint of trying to provide "more fundamental" guarantees than Rust was originally designed for (see my sibling comment on this topic). Though ideally in the long run I'd hope that no regular user would ever have to encounter it (right now I think it may show up in some contexts related to futures, but as Rust's async story matures I would hope to see that need diminish).
- jeltz 7y ago
  Ideally the basic building blocks of Rust should be so easy to understand that any experienced Rust developer could use them too and not just the core team. The cases where I personally wanted Pin were cases that I think will be solved in the future as async improves, but there are probably other more fringe cases which wont.
  - kibwen 7y ago
    Absolutely, I don't think there should be arbitrary barriers to entry for people who wish to dive into the deepest parts of Rust's type system. Finding a suitable replacement for `Pin` would be such a big task that I'd say it's not worth considering for anything short of a hypothetical "Rust 2", but hopefully in the meantime we'll soldier on and get a better idea of the problem space in the meantime.
- fluffything 7y ago
  Pretty much anybody writing `async` code, using `Futures`, etc. needs to deeply understand `Pin`, pinning, etc. Otherwise it is impossible to become productive with that part of the language.
  - steveklabnik 7y ago
    End users will almost never need to deal with pinning whatsoever; they'll be writing code with async/await.
    - the_mitsuhiko 7y ago
      Even with async await it’s not hard to run into it. The moment you end up wanting to box a future you run into pin.
  - staticassertion 7y ago
    I write async code and I have never, ever used Pin.
  - withoutboats 7y ago
    This was certainly not our intention, or what I've heard from users.
    - fluffything 7y ago
      How on earth do you write your own `Future` type without understanding pinning ? Or your own combinator? Or executor ? Or how do you understand the error messages when trying to Box or Rc a future? Or write an `async` abstraction over some C FFI component that you need to use? Or... If the goal was for users to just use high-level web frameworks, and when there is something that the framework cannot do (which is currently a lot), the expectation is that users should just shrug their shoulders and tell their bosses "Sorry boss, Rust can't do that", then sure, there is no need to understand pinning. But such users do not need to use Rust either, an pretty much any other programming language like Go or Python would have been a much better fit for them.
      - withoutboats 7y ago
        There is a huge gradient of use cases between "high level web frameworks" and "writing everything from scratch" and we've thought about the impact on users at every step of that gradient. But I'm not about to explain it to you, because you are being disingenuous and aggressive.
jedisct1 7y ago
I've been writing Rust code for 6 years and I don't understand `Pin`/`Unpin`. At best, when using futures, I randomly wrap things in `Pin<Box<..>>`, hoping that the compiler might stop complaining.
- pornel 7y ago
  Same here. It was a clever hack to move Futures forward without (it seemed) needing changes to the language. But for the sake of simplicity, I'd prefer Rust to have some first-class language construct for self-referential structs.
  - withoutboats 7y ago
    No one has ever proposed a solution - first class or not - which wouldn't be significantly more invasive and infectious. Does it sound fun in code that doesn't have anything to do with futures to spend time worrying if this generic should be `T: ?Move` or not?
amluto 7y ago
One thing I find deeply unintuitive about Pin: Pin means “this object will never ever be moved,” not “this object will not be moved while it is pinned.” I can imagine an easier-to-understand world in which there is a reference type from which one cannot move during the lifetime of the reference, and in which one only ever gets this type of reference to immovable closures and such. I don’t know if the details would work out, but it would at least seem less weird to me.
- withoutboats 7y ago
  The name for that reference type is a shared reference. It's literally the default reference type. It's not a sufficient guarantee for the use cases Pin supports.

by jeltz 7y ago

kibwen 7y ago

Agreed that `Pin` is imposing by dint of trying to provide "more fundamental" guarantees than Rust was originally designed for (see my sibling comment on this topic). Though ideally in the long run I'd hope that no regular user would ever have to encounter it (right now I think it may show up in some contexts related to futures, but as Rust's async story matures I would hope to see that need diminish).

jeltz 7y ago
Ideally the basic building blocks of Rust should be so easy to understand that any experienced Rust developer could use them too and not just the core team. The cases where I personally wanted Pin were cases that I think will be solved in the future as async improves, but there are probably other more fringe cases which wont.
- kibwen 7y ago
  Absolutely, I don't think there should be arbitrary barriers to entry for people who wish to dive into the deepest parts of Rust's type system. Finding a suitable replacement for `Pin` would be such a big task that I'd say it's not worth considering for anything short of a hypothetical "Rust 2", but hopefully in the meantime we'll soldier on and get a better idea of the problem space in the meantime.
fluffything 7y ago
Pretty much anybody writing `async` code, using `Futures`, etc. needs to deeply understand `Pin`, pinning, etc. Otherwise it is impossible to become productive with that part of the language.
- steveklabnik 7y ago
  End users will almost never need to deal with pinning whatsoever; they'll be writing code with async/await.
  - the_mitsuhiko 7y ago
    Even with async await it’s not hard to run into it. The moment you end up wanting to box a future you run into pin.
- staticassertion 7y ago
  I write async code and I have never, ever used Pin.
- withoutboats 7y ago
  This was certainly not our intention, or what I've heard from users.
  - fluffything 7y ago
    How on earth do you write your own `Future` type without understanding pinning ? Or your own combinator? Or executor ? Or how do you understand the error messages when trying to Box or Rc a future? Or write an `async` abstraction over some C FFI component that you need to use? Or... If the goal was for users to just use high-level web frameworks, and when there is something that the framework cannot do (which is currently a lot), the expectation is that users should just shrug their shoulders and tell their bosses "Sorry boss, Rust can't do that", then sure, there is no need to understand pinning. But such users do not need to use Rust either, an pretty much any other programming language like Go or Python would have been a much better fit for them.
    - withoutboats 7y ago
      There is a huge gradient of use cases between "high level web frameworks" and "writing everything from scratch" and we've thought about the impact on users at every step of that gradient. But I'm not about to explain it to you, because you are being disingenuous and aggressive.

jedisct1 7y ago

I've been writing Rust code for 6 years and I don't understand `Pin`/`Unpin`. At best, when using futures, I randomly wrap things in `Pin<Box<..>>`, hoping that the compiler might stop complaining.

pornel 7y ago
Same here. It was a clever hack to move Futures forward without (it seemed) needing changes to the language. But for the sake of simplicity, I'd prefer Rust to have some first-class language construct for self-referential structs.
- withoutboats 7y ago
  No one has ever proposed a solution - first class or not - which wouldn't be significantly more invasive and infectious. Does it sound fun in code that doesn't have anything to do with futures to spend time worrying if this generic should be `T: ?Move` or not?

amluto 7y ago

One thing I find deeply unintuitive about Pin: Pin means “this object will never ever be moved,” not “this object will not be moved while it is pinned.” I can imagine an easier-to-understand world in which there is a reference type from which one cannot move during the lifetime of the reference, and in which one only ever gets this type of reference to immovable closures and such. I don’t know if the details would work out, but it would at least seem less weird to me.

withoutboats 7y ago
The name for that reference type is a shared reference. It's literally the default reference type. It's not a sufficient guarantee for the use cases Pin supports.