[MuffinFlavored]

Future being stabilized to me is confusing. You still need `tokio` or a runtime to spawn them into an executor in order to do anything with them, right?

So you have a standard trait from the language officially, that is useless without a third party library?

[steveklabnik]

Sort of yes and sort of no. What you need is to call poll at the appropriate time. Doing so does not, strictly speaking, require external libraries. That said, you probably don’t want to write that code yourself; the naive implementation will be extremely inefficient. This is where external libraries come in.

The reason they’re external is, depending on what you want to do, you’ll want an executor with different characteristics. An embedded executor has very different needs than a network IO executor than a GUI event loop. By stabilizing the trait, we can ensure library compatibility: everyone agrees on the same interface.

Given that we’ve invested so much in making it easy to add libraries to your project, including a single one wouldn’t be appropriate.

[MuffinFlavored]

I'm not sure what this is worth, but I'd personally feel better and take Rust more seriously if they had an implementation as good as Tokio's available as part of the standard library instead of it being split across a bunch of third party libraries.

Are there talks to make that a reality in the next 18 months?

Is `async / .await` going to be just syntactic sugar around `Future` or is it going to necessitate an executor lives in the standard library?

[GolDDranks]

I don't think it's going to happen. The "Rust way" is to simply live with the fact that it's not "batteries included". Cargo means that Rust comes with "batteries reliably delivered" kind of service, and I think that has been more beneficial for the community in the long run.

async / .await are going to turn functions into Futures, and they by themselves don't necessitate an executor any more than the Future trait itself.

[pjmlp]

Only if those libraries are upheld to a specific quality level and available in every single platform that Rust is able to target.

Here Java, .NET and future C++ are a clear winner, given that they are part of the standard library.

[steveklabnik]

Async await is already syntactic sugar for futures, and does not require any specific executor.

There’s no plans to add an executor to std for all the reasons I’ve said.

[pjmlp]

Which makes Rust stand out versus what Java and .NET already do, and what C++ will do (even if they are only fully done by C++23).

Standard library executors are guaranteed to be available across all platforms supported by the compiler, with a validated level of quality for production loads.

Random implementation from Internet not so much.

[roca]

There are no real advantages to putting Tokio in the standard library. Cargo makes it trivial to manage the dependency.

There are some real disadvantages to putting Tokio in the standard library, for example tying Tokio releases to the standard library release cycle and making it difficult/impossible for people to use non-latest versions of Tokio.

[MuffinFlavored]

Look at all of the flack the JavaScript ecosystem gets for having everything as a "dependency", and in this thread 3 people are cheering that Rust makes the executor required to do anything with Futures a third party library. Wild.

[kibwen]

In this case the Future trait puts the "standard" in "standard library" by providing an agreed-upon interface by which third-party crates can interact without conflicts. There's a high bar for adding new modules to the stdlib, and fundamental building blocks like Future are far, far easier to accept than, say, the entire Tokio stack.

Note as well that Tokio isn't the only library that can be used here, there's plenty of experimentation in this space.

[CryZe]

In addition to what the others said there's another point: async fn's implement Future, otherwise you wouldn't be able to use them. So it's essential for Future to be in the standard library so that async fn can work.

[bjterry]

I think that allows library authors to implement against the trait, but then the user of that library can choose which concrete implementation they want to use in their app, so they don't have to have multiple and convert between them.