Iced: None of the async examples are actually async

[thomhuds]

There are multiple functions in the example applications which are marked as async but don't use .await at all, instead doing blocking I/O. This means that if there are more tasks running than there are threads in the thread pool, the executor will only run the ones that got there first, as they are blocking the worker threads. For example in examples/pokedex.rs the search function is marked as async but makes HTTP requests using reqwest's sync API, which defeats the purpose of using async functions. In order to make use of the new async functions, they need to only use async I/O.

[hecrj]

Yes, I am aware of this.

Considering the examples using async only run a single Command at once, I think the chances of running out of threads are a bit low.

The examples were meant to show how you can use futures with the library to run stuff in the background. They are not meant to showcase proper use of async I/O (they do not even have proper error handling). Even if you use blocking I/O, an async function is still useful as it gives you opacity and lets you change the implementation to something non-blocking in the future.

That said, I agree we should fix this. The last thing we want is for users to think that just slapping async everywhere makes everything magically work.

Coincidentally, I fixed the pokedex example yesterday in #122, by using surf instead and performing both requests concurrently. reqwest async API is still in alpha and uses tokio, which has executor lock-in.

I also just went ahead and ported the todos example to async-std.