Futures: Exploring Rust's futures in Swift

Hello all! I've been fascinated by Rust's poll-based approach [1] to async programming so I've been working on a library for quite a while now, which you'll find here: https://github.com/dfunckt/swift-futures.

What's so nice about this? Turning the traditional callback-based approach of "I'll call you when I'm ready" into "let me know if I should check back next time" simplifies semantics a lot -- eg. you always know which thread your code is going to be called on, you can avoid memory allocations and locks at runtime, you can get firm control over cancellation and back-pressure, and more. What's also interesting is you also get to use value types everywhere which the compiler happily optimises out, à la SwiftUI, which means extremely low overhead and great performance.

It's still early days for the project. Ultimately, I hope it'll be a useful alternative to reactive libraries out there, but also a playground to explore language features (such as move-only and opaque types) as they arrive.

[1] interesting read: http://aturon.github.io/tech/2016/09/07/futures-design/

6 Likes

Hey! What are your thoughts on your SPM package in relation to Combine (which also has the Future Publisher

I try to highlight a few things that when considered together make Futures unique in the "Why Futures?" section of the README. At the moment, if you're into SwiftUI, you'll probably want to stick with Combine given how well integrated it is. For everything else I'd seriously consider Futures. I'd love to have adapters in Futures that let one go from Combine to Futures and vice versa at some point -- there's no inherent reason you can't use Combine for the UI and Futures for everything else.

Terms of Service

Privacy Policy

Cookie Policy