There is also a `tokio02` feature which let's you run tokio inside of async-std.
The problems are:
- The global `spawn` method need to know on which executor to spwan thinks, the ones for tokio look for a tokio executor the ones for `async-std` for a async std one.
- The async-io implementations might require to be run in the executor they are shipped with.
- Some combinators shipped with some runtimes also need to be run in that runtime.
This is a bit annoying. I believe everyone involved would have preferred a single general purpose runtime, but to all kinds of reasons this didn't work out.
The original plan was to provide generic interfaces in the futures library so that most code (including things like grpc) can be independent of the runtime.
But people couldn't agree on a common interface. The main problem was around how to do the `AsyncIo` trait and timers.
Since the introduction of async/await the runtimes have converged a lot more in their external interfaces, and there are plan to put `AsyncRead`/`AsyncWrite` traits into std.
After this the divergence problem might maybe be fixed slowly.
---
To provide some more information about the problem:
Basically a executor consists of three parts:
1. The thing driving/running/polling futures.
2. A reactor handling the async io details.
3. Something to handle things lie `Delay`/`Timeout`.
For the first point the problem is a missing standardized way to `spawn` new independent futures and another way to do so locally (`LocalExecutor`/`LocalSet`).
For the second point it's not so likely that things will converge but we could agree on a way to have multiple `Reactors` running in parallel or similar in ways which should "just work" without to much overhead.
For the third point people currently can't agree one specific implementation as far as I remember once they do we might at least have a generic timer interface.
Anyway by now most of the (new) external APIs of both async-std and tokio now mirror std (tokio copied that once it turned out it was a good idea).
This also means that most implementations can be made to work with any executor by having a feature for any of the executors and then depending on the feature import different things, for most parts most of the code will just work by importing think from async-std instead of think from tokio.
There is also a `tokio02` feature which let's you run tokio inside of async-std.
The problems are:
- The global `spawn` method need to know on which executor to spwan thinks, the ones for tokio look for a tokio executor the ones for `async-std` for a async std one.
- The async-io implementations might require to be run in the executor they are shipped with.
- Some combinators shipped with some runtimes also need to be run in that runtime.
This is a bit annoying. I believe everyone involved would have preferred a single general purpose runtime, but to all kinds of reasons this didn't work out.
The original plan was to provide generic interfaces in the futures library so that most code (including things like grpc) can be independent of the runtime.
But people couldn't agree on a common interface. The main problem was around how to do the `AsyncIo` trait and timers.
Since the introduction of async/await the runtimes have converged a lot more in their external interfaces, and there are plan to put `AsyncRead`/`AsyncWrite` traits into std.
After this the divergence problem might maybe be fixed slowly.
---
To provide some more information about the problem:
Basically a executor consists of three parts:
1. The thing driving/running/polling futures.
2. A reactor handling the async io details.
3. Something to handle things lie `Delay`/`Timeout`.
For the first point the problem is a missing standardized way to `spawn` new independent futures and another way to do so locally (`LocalExecutor`/`LocalSet`).
For the second point it's not so likely that things will converge but we could agree on a way to have multiple `Reactors` running in parallel or similar in ways which should "just work" without to much overhead.
For the third point people currently can't agree one specific implementation as far as I remember once they do we might at least have a generic timer interface.
Anyway by now most of the (new) external APIs of both async-std and tokio now mirror std (tokio copied that once it turned out it was a good idea).
This also means that most implementations can be made to work with any executor by having a feature for any of the executors and then depending on the feature import different things, for most parts most of the code will just work by importing think from async-std instead of think from tokio.