3 ms·
The issue isn't exactly that it's not ready for prime time, but that it's not ergonomic at the moment. The biggest issue that you have to get used to is that pr
by bluejekyll 8y ago
The issue isn't exactly that it's not ready for prime time, but that it's not ergonomic at the moment. The biggest issue that you have to get used to is that pretty much everything has to be owned data, and no references passed around when constructing Future types. This can feel like it comes into conflict with the poll(&mut self) interface (in 0.1).
Also, I found truly understanding the fact that returning data from functions either must be sized or boxed, no references. Again, the &mut self can come into conflict here. But there are simple tricks for dealing with it, like using inner enums for iterating through a state machine of the future, and using Option where you can take() the value when ready.
You'll see these patterns if you look at the Future library and Tokio impls of many of the core types. So I encourage you to generate docs with `cargo doc` and then click the `src` link on any types you want to understand better. The thing I wish I had internalized more earlier (and have been cleaning up a lot lately), is that "Futures should do no work unless polled". This is easy to mess up and regret later as you might accidentally start a Timer or initiate a connection before polling the Future.
Anyway, hopefully people help out when you ask, though everyone's often busy :)
- nevi-me 8y agoOne of the challenges I'm having now is with some library that connects to a steaming pubsub server. I found a problem with the library, my use-case differs from what's being tested, and because I'm struggling to use the library the way the author suggests; I'm unable to convince them that being unable to Clone their data structure is causing a problem. I unfortunately am not at the point of "X didn't work, so I wrote Y" as that's how we end up with competing libraries.
- bluejekyll 8y agoSometimes there are good reasons for not cloning, such as underlying resources that can’t be cloned. But I agreed it can be ergonomically easier in many cases. If they truly don’t want it, and you really don’t want to fork, can rewrapping it in an Arc<T> or Arc<Mutex<T>> get you around the problem?
- deepsun 8y agoWait, if I do (in any language) foo = createFuture(1) bar = createFuture(2) foo.poll() bar.poll() I would expect them to start doing work before polled, otherwise there'd be no concurrency. Do I undsrstand you correctly about polling?
- steveklabnik 8y agoYou didn’t say what you understood, but nothing would happen until poll is called in Rust. And calling poll would only result in one churn of the event loop. You don’t call poll yourself, you put the future onto an event loop and it calls poll for you.