[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.