zlacker

I was really hoping that there'd be movement on a comment without-boats made in https://without.boats/blog/why-async-rust/ to bring a pollster like API into the standard library.

Rust has very good reasons for not wanting to bless an executor by bringing it into the standard library. But most of those would be moot if pollster was brought in. It wouldn't stifle experimentation and refinement of other approaches because it's so limited in scope and useless to all but the simplest of use cases.

But it does in practice solve what many mislabel as the function coloring problem. Powerful rust libraries tend to be async because that's maximally useful. Many provide an alternate synchronous interface but they all do it differently and it forces selection of an executor even if the library wouldn't otherwise force such a selection. (Although to be clear such libraries do often depend on I/O in a manner that also forces a specific executor selection).

Pollster or similar in standard library would allow external crates to be async with essentially no impact on synchronous users.

>>bryanl+(OP)
`pollster` in the stdlib would probably make sense. But of course there's nothing stopping anyone from using the `pollster` crate today.

>>bryanl+(OP)
Not quite yet. Crates like reqwest and hyper tend to use tokio's io types internally to set up the sockets correctly and send/receive data at the right time. Those might have different APIs than the thread-pausing sync APIs.

Sans-IO crates exist but are kind of annoying to schedule correctly on an IO runtime of choice. Maybe lending iterators could help idk

>>nicobu+mG
Pollster in the standard library provides several major benefits outside of just using it yourself.

- it provides an incentive for libraries to be pollster compatible, rather than requiring tokio. And pollster compatible means executor agnostic.

- libraries would document their library with pollster usage