[geofft]

I would worry this would end up like Python, where there is a default async executor in the standard library (asyncio) which was previously developed outside of the standard library (Tulip), but a) it's changed a fair bit between versions, even recently, as they figured out better ways to do things and b) there's been significant work on differently-structured executors (Curio and Trio, notably) as third-party libraries. As an end user of Python, I want to basically entirely use Trio, but there's a fair amount of async Python out there that's been written to assume asyncio.

(There is, at this point, an abstraction library called "anyio" which can run on either an asyncio or Trio event loop, but anyio's model is most strongly influenced by Trio's, because Trio's model is more structured - which means anyio couldn't have been written before Trio was developed and well-received.)

Given that Python has a strong "batteries included in the standard library" approach and Rust has a strong "we shipped a really good package manager with the language, and even the C 'int' type lives outside the standard library, in a package maintained by the Rust core team" approach, it seems like it would be very weird for Rust to repeat the mistake (at least in Rust's worldview) of shipping a default executor in the standard library that would turn into a de facto standard.

And given that Rust does have a really good package manager, adding a third-party dependency is pretty straightforward and doesn't seem like too much of an obstacle. (Frankly, the same is also true of Python, and I would certainly tell a beginner to make a virtualenv and pip install Trio. But since it didn't have it since day one, there's more of a cultural expectation to make the standard library useful out of the box.)