What's the alternative? I'm happy to use tokio, but i'm happy other folks can enjoy other executors (smol, async-std, glommio, etc). I think the situation is OK because tokio is well-maintained, even though it's not part of the standard library, and i'm afraid making it part of the standard library would make it harder to use other executors, and harder to port the standard library to other platforms.

But maybe my fears are unfounded.

▲

nicoburns an hour ago | parent | next [-]

> What's the alternative?

Traits in the stdlib for common functionality like "spawn" (a task) and things like async timers. Then executors could implement those traits and libraries could be generic over them.

	▲	josephg 35 minutes ago \| parent [-]
		Yep. We could have a system like how there's a global system allocator, but you can override it if you want in your app. We could have something similar for a global async executor which can be overridden. Or maybe you launch your own executor at startup and register it with std, but after that almost all async spawn calls go through std. And std should have a decent default executor, so if you don't care to customise it, everything should just work out of the box.

▲

ignoreusernames 2 hours ago | parent | prev | next [-]

As of now I don’t think there’s an alternative. I’m not a Rust expert but the core issue to me is that “async” goes beyond just having a Futures scheduler. Async stuff usually needs network, disk, os interaction, future utilities(spawn) and these are all things the runtime (tokio) provides. It’s pretty hard to be compatible with each other unless the language itself provides those.

▲

turdinthemouth an hour ago | parent [-]

That's not the core issue at all it's lifetimes and allocations.

	▲	ignoreusernames 36 minutes ago \| parent [-]
		Can you elaborate on this please? Do you mean that’s basically impossible for rust std to provide a default runtime that makes “everyone” (embedded on one end and web on the other) happy?

▲

oersted an hour ago | parent | prev [-]

It would make sense to have an official default async runtime in the standard library while keeping the door open to use any other runtime, just like we already have for the heap allocator or reference counting garbage collection.

There are issues in particular with core traits for IO or Stream being defined in third-party libraries like tokio, futures or its variants. I've seen many cases where libraries have to reexport such types, but they are pinned to the version they have, so you can end up with multiple versions of basic async types in the same codebase that have the same name and are incompatible.