The problem is that this.. preference.. isn't made clear or justified anywhere. I use `async_std` because its value prop is "the stdlib but for async". I don't want some weird thing called `tokio` in my codebase with extra bells and whistles I don't need. async-std is a minimal simple fast async runtime for Rust. I am aligned with their vision and love using it. async-std works flawlessly and only really lacks more comprehensive stream support which I augment with the futures crate as is pretty standard.
If yall want everyone to use Tokio then tell me why it's better than async_std. Tell me why it's the de-facto community standard. Because "popular web framework" uses it? Why are all the cool kids using it? Because the others are?
No. Either I want some group with authority to bless a core async runtime implementation that aligns with Rust's philosophy and value prop and bring it under their wing so that it can be made to serve the goals of the project which might include being configurable enough to deploy in all of the myriad scenarios and environments where people use Rust today.
Or in lieu of that, provide the necessary abstraction layer so everyone can bring their own executor like it's supposed be.
The entire premise of Rust not providing a blessed implementation is so that people could pick and choose based on their preferences and use cases. That's the argument. The reality is that the goal is not realized because Rust has not done the work to enable everyone to simply bring their own runtime and call it day. So Rust has not delivered on the core reason for not shipping a runtime in the first place.
The solution of "just use a de-facto blessed runtime" really seems like a concession if Rust's argument for not having one is to be respected.
> If yall want everyone to use Tokio then tell me why … it's the de-facto community standard.
> I want some group with authority to bless a core async runtime implementation…
Hmm, if Tokio is the de-facto community standard, isn’t that saying that the authority of “people who write and run async code for actual production systems” is blessing it as a preferred option?
> The reality is that the goal is not realized because Rust has not done the work to enable everyone to simply bring their own runtime
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, and Tokio is the only project that has actually done it.
> 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.
If yall want everyone to use Tokio then tell me why it's better than async_std. Tell me why it's the de-facto community standard. Because "popular web framework" uses it? Why are all the cool kids using it? Because the others are?
No. Either I want some group with authority to bless a core async runtime implementation that aligns with Rust's philosophy and value prop and bring it under their wing so that it can be made to serve the goals of the project which might include being configurable enough to deploy in all of the myriad scenarios and environments where people use Rust today.
Or in lieu of that, provide the necessary abstraction layer so everyone can bring their own executor like it's supposed be.
The entire premise of Rust not providing a blessed implementation is so that people could pick and choose based on their preferences and use cases. That's the argument. The reality is that the goal is not realized because Rust has not done the work to enable everyone to simply bring their own runtime and call it day. So Rust has not delivered on the core reason for not shipping a runtime in the first place.
The solution of "just use a de-facto blessed runtime" really seems like a concession if Rust's argument for not having one is to be respected.