4 ms·

Pin is another one. I still can’t wrap my head around it. I’m sure it’s simple and the docs are great, but having read them multiple times I’m not really more c

Pin is another one. I still can’t wrap my head around it. I’m sure it’s simple and the docs are great, but having read them multiple times I’m not really more clear. I probably need to see a bunch of hands on examples. I wish they’d gone the Move route instead of rushing to 1.0 and then retrofitting in Pin. But I agree, in general things in rust are a lot more thought out and experiments are relegated to unstable which is fine with breaking changes. I do wish though that they had a better versioning story in the language for making backward incompatible changes more a matter of course. It’s great already for “user space” code via editions, but as the author notes making certain kinds of changes brings up risk and uncertainty because there’s not a well trodden path to support changing core semantics in the language and having it work gracefully without needing a migration en masse.

majewsky 3y ago
> I wish they’d gone the Move route instead of rushing to 1.0 and then retrofitting in Pin. That is easy to say, and I don't disagree with the sentiment, but there are valid reasons for setting a 1.0 release date and cutting corners to get there. If they had not done that, there probably was a real risk of running an infinite loop of "let's wait for Move to be implemented", "great, now let's wait for Leak to be implemented", "great, now let's wait for..." and a 1.0 never gets put out. Rust may not be perfect, but at least it's stable and people are actually using it.
cmrdporcupine 3y ago
Pin used to confuse me, but now it's clearer. It's right in the name: Pin this thing to where it is in memory, never try to move it. Rust can and does move things around as it feels the need. So you need something like Pin if what you've built can't move. It's confusing if you're coming from a C++ background because in C++ something only "moves" if you explicitly std::move it. In Rust its effectively the reverse. A crude way of thinking about Rust's call pattern is that it's basically the opposite: as if every call was a std::move operation. So Pin is basically just saying: you can't move this, don't try. The memory can't be moved. And it's mostly used in corner cases where some kind of explicit memory management is involved. Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries.
- laurencerowe 3y ago
  > Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries. Don’t all Rust users writing async code have to worry about Pin?
  - brigadier132 3y ago
    Not really, the async libraries hide the implementation details from you. It's an issue for library developers.
  - cmrdporcupine 3y ago
    I've never had to and I have stuff that uses async all over. The only time I've seriously had to deal with Pin is for some pretty low level stuff: manual memory/heap management for database datastructures (paged btree) and for some work stuff related to working with a C++ library that uses zeromq, etc. The point being that in both cases these were frobby dark corners where the mechanics of the pinning ends up being hidden from the user. People writing application code in Rust should not encounter it often.
    - hedora 3y ago
      You get to avoid pin until you can’t, and then it’s because of some terribly unintuitive advanced usage corner case. For instance, the async_stream crate would be much nicer if you didn’t need to pun_mut! the stream instances it provides: https://docs.rs/async-stream/latest/async_stream/ https://docs.rs/async-stream/latest/async_stream/
- vlovich123 3y ago
  Conceptually I understand the motivation. But trying to figure out how to express it frustrates me so much that eventually I just gave up.
  - cmrdporcupine 3y ago

majewsky 3y ago

> I wish they’d gone the Move route instead of rushing to 1.0 and then retrofitting in Pin. That is easy to say, and I don't disagree with the sentiment, but there are valid reasons for setting a 1.0 release date and cutting corners to get there. If they had not done that, there probably was a real risk of running an infinite loop of "let's wait for Move to be implemented", "great, now let's wait for Leak to be implemented", "great, now let's wait for..." and a 1.0 never gets put out. Rust may not be perfect, but at least it's stable and people are actually using it.

cmrdporcupine 3y ago

Pin used to confuse me, but now it's clearer. It's right in the name: Pin this thing to where it is in memory, never try to move it. Rust can and does move things around as it feels the need. So you need something like Pin if what you've built can't move. It's confusing if you're coming from a C++ background because in C++ something only "moves" if you explicitly std::move it. In Rust its effectively the reverse. A crude way of thinking about Rust's call pattern is that it's basically the opposite: as if every call was a std::move operation. So Pin is basically just saying: you can't move this, don't try. The memory can't be moved. And it's mostly used in corner cases where some kind of explicit memory management is involved. Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries.

laurencerowe 3y ago
> Most Rust users should not have to worry about it. It's one of those things that becomes more of a concern if you're writing library code for low level datastructures, or interfacing with C/C++ libraries. Don’t all Rust users writing async code have to worry about Pin?
- brigadier132 3y ago
  Not really, the async libraries hide the implementation details from you. It's an issue for library developers.
- cmrdporcupine 3y ago
  I've never had to and I have stuff that uses async all over. The only time I've seriously had to deal with Pin is for some pretty low level stuff: manual memory/heap management for database datastructures (paged btree) and for some work stuff related to working with a C++ library that uses zeromq, etc. The point being that in both cases these were frobby dark corners where the mechanics of the pinning ends up being hidden from the user. People writing application code in Rust should not encounter it often.
  - hedora 3y ago
    You get to avoid pin until you can’t, and then it’s because of some terribly unintuitive advanced usage corner case. For instance, the async_stream crate would be much nicer if you didn’t need to pun_mut! the stream instances it provides: https://docs.rs/async-stream/latest/async_stream/ https://docs.rs/async-stream/latest/async_stream/
vlovich123 3y ago
Conceptually I understand the motivation. But trying to figure out how to express it frustrates me so much that eventually I just gave up.
- cmrdporcupine 3y ago