4 ms·
The position of the async-std project is that people should use _futures-rs_ as the integration point and avoid integrating into tokio or async-std if possible.
by Argorak 7y ago
The position of the async-std project is that people should use _futures-rs_ as the integration point and avoid integrating into tokio or async-std if possible. (both are IO optimised)
Especially for things like an actor system, I would recommend to not use either, but instead spawn a dedicated number of threads handling the actors. This allows you to be specifically optimised to the problem. bastion is a great example for that.
async-std ships a second library called "async-task", which implements just the task/future allocation component and allows you to quickly implement your own runtime.
Full disclosure: I'm one of async-std's maintainers.
- xiphias2 7y agoI understand this, but it still doesn't answer the main point: are you working together with tokio maintainers to move to futures-rs as soon as possible and even extend the interface of futures-rs more if needed? In my view the separate interfaces increase the long term damage that new libraries are creating every day, and it should be higher priority to resolve it together before implementing new features in either of the two libraries (async-std and tokio).
- Argorak 7y agoWe don't maintain futures-rs. But for the reasons you outline above (stability), our interface is also effectively done. The choice of not using all of futures for their interface is outspoken the strategy of tokio. We have encouraged them to prefer the futures layers, but we don't see the work happening. So, to answer your question: we are not working with them, the place of collaboration is futures-rs.
- ComputerGuru 7y agoI have heard that using the async-std APIs (but not the reactor and executor) causes background futures to be spawned to the async-std specific executor. I’m not sure of the veracity of this claim, can you comment?
- Argorak 7y agoSooo... in standard profile, yes. `async_std::spawn` uses async-stds runtime. Also, our io interfaces (TcpListener, etc.) are effectively bound to our runtime (they need our mio instance in the back). But this cannot made work generically in the current ecosystem, as there are no common abstractions here. We can't come up with those unless we have buy-in from other players. For applications, that doesn't really matter: you pick one Listener type and you're done. Applications aren't very generic. For libraries, that's harder, but there's strategies around that make it feasible to work with this situation (mainly: injecting the exact type to use into your library). Finally: there's a flag in async-std called "runtime". If you turn it off, you can use async-std without that behaviour, at the cost of having to bring your own runtime.
- ComputerGuru 7y agoThank you. I’m mainly concerned with library development, so I found your answer helpful.
- Argorak 7y agoWe're working on the rest :). Look out for some announcements in the coming days and weeks.
- mamcx 7y agoLet me derail a little: Which one is better to have a coroutine like experience?