Futures are the interface for asynchronous code. You need some sort of executor to actually drive the chain of futures to completion. Tokio is the most popular option, but is not required, strictly speaking. You can whip up a simple executor with nothing but the standard library. It won’t perform as well as Tokio, of course. There’s a good reason it’s a big project.
(Tokio is built on top of mio so if you’re using Tokio, you’re using mio)
Doesn't futures 0.3-alpha bring its own executor? I haven't followed Tokio too closely recently, but my understanding was that, going forward, futures provides the executor and Tokio provides the reactor. At least, that would be a division that would make sense to me.
futures-preview 0.3 does have futures::executor::ThreadPool; a simple thread-pool based executor. However, I thought that tokio did its own thing here. I could be wrong.
That is right. And while it theory having a separate executor (eg in the futures lib) and IO providers (timers, sockets) in another lib works it will in practice never be as efficient as having an integrated system like Tokio. The reason for that is that decoupled solutions can’t integrate the reactors in the same eventloop and there is always extra synchronization and thread hopping involved. The difference can be huge, eg 50% less throughout on a server.
(Tokio is built on top of mio so if you’re using Tokio, you’re using mio)