History and future of futures, futures-preview, std::future?

Hi,

I recently started learning non-blocking async I/O in Rust. Obviously, my research had reached to futures and Tokio so I'm trying to understand Tokio and futures.

My first surprise was there are multiple futures crates. After some research, I got to know the futures 0.1 is the version I have to use for now. And the version 0.2 was yanked and 0.3 is WIP as futures-preview. Got it.

But I found the other, std::future is coming. Is it an effort to include futures crate to standard library? What is the relation of futures-preview and std::future? What is the expected landscape once the both std::future and futures 0.3 are released?

Thank you!

5 Likes

Did you happen to stumble on Tracking issue for async/await (RFC 2394) · Issue #50547 · rust-lang/rust · GitHub?

The tl;dr; is Rust will gain language-level async support (via the async and await keywords) for expressing asynchronous actions. The compiler will synthesize state machines and types on your behalf - these types need some interface to conform to so they can be scheduled and executed by the various event loops/executors/reactors in the wild (tokio being the most well known and used). So, to that end some core types (traits mostly, I believe) need to live in std - notably, Future. If you're familiar with C#, it's quite similar (in spirit) to their async/await syntax coupled with the Task type.

I might be off in some details as I've honestly not kept up-to-date on the bleeding edge of this, but that's the general high-level story here, AFAIK.

5 Likes

Both have the same trait Future, using re-exports. Clicking the src in this doc link. I believe the intent is to keep the absolute minimal in core/std so in all likely-hood you will need Futures crate to create libraries using async functionality and the binary will need some executer too.

2 Likes

@vitalyd and @jonh are correct. To expand a bit more, the intent is that the most fundamental abstractions will live in std (and core for no_std usecases), the futures crate (in versions 0.3 and later) will then provide two things on top of that: a nursery for core abstractions that aren’t stable enough to be in std yet, and utilities built on the core abstractions to make async programming easier.

The sort of core abstractions provided by futures that may move into std in the future is things like Stream for async iterators, Spawn for spawning off independent async tasks, the io related traits, etc.

The utilities are things that are executor/IO framework independent. Some parts of these may move into std in the future as well, and they are much less necessary with async/await support; but just like Result::map is useful in some situations even with ?, FutureExt::map etc. can be useful as well.

3 Likes

@vitalyd, @jonh, @Nemo157. Now it became clear. Thank you very much!!

This thread helped a lot to understand all of the different future bits that are out there. Rust 1.36 finally added the std::future::Future type into the stable builds, but I still don't understand what the plan is for Sink and Stream. Are those going to eventually be added to std too? Is the futures 0.3 crate going to exist post std::future?

I believe (at least in the short term) the plan is for a minimal subset of functionality to be in std (pretty much just Future and the executor primitives), and then for the futures crate to extend that with richer layers on top. For example, the Future trait in std does not include any combinators like and_then. Presumably those will remain in futures as part of an extension trait.

Long term, I'm not sure what the plan is. My hope is that it'll follow a similar pattern to itertools/crossbeam/etc - prove the needs/implementation in an external crate, then add to std once it's rock solid.

2 Likes