No, it's not the standard.

There has been some friction between the two groups (tokio and async-std) unfortunately.

I'm not sure what the original source of friction was, but bad feelings seem to seep out when the projects are discussed in active Rust communities. I wonder how long the drama will go on. But at least both parties seem to be trying to be civil about it (and succeed).

Folio => Tokio

Now that is another nice name in search of an async/await project.

Argh. Thank you. I caught that autocorrect once but then reworded things.

> should be resolved ASAP

I'm not sure having multiple runtimes is such a problem. The Rust async IO model was explicitly designed to accommodate different runtimes. There are a lot of tradeoffs around how a runtime does multi-threading, for example, and embedded systems may also do their own thing. Tokio vs async-std might or might not make sense as a long term split, but I think it's too early to say.

I think the main clash was not about runtime differences but about the interface incompatibility (futures.rs)

There's a bug for it in Tokio, but it's low priority as far as I know.

https://github.com/tokio-rs/tokio/issues/1297

It's not particularly low priority https://github.com/tokio-rs/tokio/pull/1744

(See the last section in particular)

This is a great thread! Lots of different perspectives on a difficult technical problem, plus appearances from many of my favourite Rust characters: we've got Ralf telling everyone that only abstract machines exist, boats turning up halfway through to contradict everyone, and Douman dropping by to offer the unhelpful C++ perspective.

Oh, so there's a pull request that I didn't see, the bugs don't show that it's being worked on.

I understand that there are lots of hard technical issues to be resolved, it's just the visibility of this pull request wasn't that good.

Thanks for the answer!

Very interesting thread.

> I think the main clash was not about runtime differences but about the interface incompatibility (futures.rs)

There is a huge amount of complaints just fundamentally about async-std's existence, though.

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.

I 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).

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

I 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?

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

Thank you. I’m mainly concerned with library development, so I found your answer helpful.

We're working on the rest :). Look out for some announcements in the coming days and weeks.

Let me derail a little: Which one is better to have a coroutine like experience?

None, I would suggest pushing on the stabilisation of generators ;).

Yeah, but it look like is still far away :(

There's nothing "standard" about async-std as of yet. The name is because it tries to build something that can be used just like std library facilities, except for the async support.

You are right, but I also want to point out that we fully buy into the futures-rs interface over custom implementations.

Why should it be resolved ASAP? This mentality that there should be no more than one viable solution to address a need is what needs resolving. Rust would not even exist if enough people agreed with that sentiment.