Yessssss! The Waker simplification for Futures has been merged into the main RFC! -- https://github.com/aturon/rfcs/pull/16 … So no more LocalWaker / Waker distinction. Only 1 Waker type is needed to signal a Future is ready. This means we're *so close* to having Futures land on stable!
-
Show this thread
-
I'm legit so stoked about this! Conceptually this now feels really close to how JS Promises work, but with Rust's error handling story included (no unhandled rejections possible, first class abort through panic!()), and first-class cancellation (Through Drop). Very good!
1 reply 0 retweets 11 likesShow this thread -
Oh oh, another difference: Futures are polled immediately*, allowing them to start work right away and wait for a callback. In practice this means that unlike Promises, sync Futures don't suffer from nextTick delays. * This depends on the scheduler, but it's generally true.
1 reply 0 retweets 5 likesShow this thread -
Replying to @yoshuawuyts
Maybe I'm misunderstanding, but JS promises start work right away. console.log('before'); new Promise(resolve => { console.log('working'); resolve(); }); console.log('after')
1 reply 0 retweets 0 likes -
Replying to @matthewcp
Ah yes, you're entirely right! I got confused with the difference between new Promise(), and Promise.resolve().then(). One is scheduled immediately, other is put in microtask queue — overlap in use, but def different. Thanks for the correction! https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/ …
1 reply 0 retweets 1 like
I haven't checked this but I'm thinking Rust futures *could* do away with the nextTick in chains entirely if each Future is resolved immediately. But need to verify to make sure this actually happens.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.