Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



> 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?


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.


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/


Not really, the async libraries hide the implementation details from you. It's an issue for library developers.


Conceptually I understand the motivation. But trying to figure out how to express it frustrates me so much that eventually I just gave up.


Fair. The documentation made my eyes glaze over and I got confused. It was only once I needed it that it made sense to me. And I still don't understand some uses of it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: