[stormbrew]

I really really hope this never ever happens. Tokio is great and all, but enshrining it as the default would have a stifling effect and impose a lot of design decisions all over the place.

I do hope that it becomes more possible to write async code that is portable between executors. If there were more standard traits around the most common elements of an executor it'd make things a lot better imo.

[steveklabnik]

It wasn't suggested that it be Tokio, it was suggested that it be a minimal one, that could get you started without needing to make big choices before you even begin. (And yes, portability would have to be a part of that story.)

[stormbrew]

I took the post mentioning the de-facto normalization of tokio as implying that the default could be tokio, or at least based on tokio. Maybe I misinterpreted, but that was my reading of the post I was replying to.

That said, I think no matter how minimal it is it would still be a mistake. If anything, I think the only thing that would make sense to include is basically a "not-really-async" executor to appease things like the sibling thread where people want to be able to incorporate async code into their sync codebase without spawning a reactor thread. But that would also require the ability to genericize libraries over executors (and would obviously come with some significant caveats around potential deadlocks).