> Hmm, if Tokio is the de-facto community standard, isn’t that saying that the authority of...
Being the most popular async runtime (a de-facto status) is one thing. Being a community standard voted on by the rust community and blessed as such is another.
> Or, another possibility is that it hasn’t been realized because building a robust, production-ready, well-maintained runtime is itself a lot of work...
The Rust people only need to provide a standard async abstraction layer, not build the runtime.
Then everyone can bring whichever runtime they want, which is the argument for why Rust doesn't ship/bless one.
Basically Rust wants to have its cake and eat it too. "We don't want to add an async runtime to rust because rust has a small runtime that only supports some of the features the language offers and we want to enable people to interchangeably use their own based on their own use cases and needs." vs the reality that "In order to use their own runtimes interchangeably would require an async abstraction layer which we also don't provide."
So we're left with the worst of both worlds. We have neither (a) a blessed community standard so other runtimes can die, nor (b) an abstract interface atop which authors can write async code and beneath which runtime implementers can hook in interchangeably. We have (c) a bunch of disparate little runtime ecosystems with their own sets of compatible code which can't be used together.
Being the most popular async runtime (a de-facto status) is one thing. Being a community standard voted on by the rust community and blessed as such is another.
> Or, another possibility is that it hasn’t been realized because building a robust, production-ready, well-maintained runtime is itself a lot of work...
The Rust people only need to provide a standard async abstraction layer, not build the runtime.
Then everyone can bring whichever runtime they want, which is the argument for why Rust doesn't ship/bless one.
Basically Rust wants to have its cake and eat it too. "We don't want to add an async runtime to rust because rust has a small runtime that only supports some of the features the language offers and we want to enable people to interchangeably use their own based on their own use cases and needs." vs the reality that "In order to use their own runtimes interchangeably would require an async abstraction layer which we also don't provide."
So we're left with the worst of both worlds. We have neither (a) a blessed community standard so other runtimes can die, nor (b) an abstract interface atop which authors can write async code and beneath which runtime implementers can hook in interchangeably. We have (c) a bunch of disparate little runtime ecosystems with their own sets of compatible code which can't be used together.