pollster

withoutboats mentioned trying to get something like https://github.com/zesterer/pollster into the standard library. I think that's a great idea. They don't want to put an executor into the standard library because that would "pick a winner" before the ideas are settled. But pollster allows async crates to be useful to sync code, is obviously not a "winner" and its inclusion in the standard library would force crates to be properly executor-agnostic.

I see this same situation playing out with async executors. tokio is taking over, but it doesn't play well with other async executors. I just wrote a program that mixed tokio & glib and it wasn't fun. This does feel like a soluble problem, so I hope they do figure it out. I think the first step might be something like without.boats' proposal to add something like https://github.com/zesterer/pollster to the standard library to establish a minimum common denominator.

You can spin up a single threaded runtime to perform these async calls without the need to "infect" the rest of the program. The strategy is to spin up a single threaded async runtime and to just perform that call and block on the runtime itself. The easiest way to do that is probably https://github.com/zesterer/pollster And there really isn't much in there so you didn't need to worry about performance or anything like that. I recently refactored a colleague's program from async to sync because it's essentially and entirely sequential. The reason it started its life as async was the reqwest library, which first and foremost provides async methods to perform http requests. However, tucked away behind a feature flag aptly named `blocking` there is a small API that wraps the async api and allows making sync/blocking calls in a non-async main