Regarding futures VS callbacks, I’m on the callbacks side.
futures-rs seems like a moving target at the moment and this dependency might result in several rewrites of async functions.
And I guess it shouldn’t be too hard to refactor from callbacks to futures eventually (as opposed to futures->callbacks or sync->futures). It’s not exposed in the public interface, so an internal async mechanism can be changed when it’s appropriate (e.g. when
futures-rs is stabilized at 1.0 or if async/await is incorporated into rust-stable).
Callbacks have their downsides but in any case it’s the same state machine under the hood. What I mean is that semantics don’t differ substantially, only the syntax/representation. So callbacks can be used and composed in the same way as futures (in regard to throttling, etc.).
There’s one more thing to it, though: futures have a simpler way to handle errors (with
futures-rs it’s essentially an asynchronous
Result<R,E>). I haven’t noticed anything about errors in the RFC, but I guess that there’d be 2 callback functions for success/failure and that might add more complexity to code.