That’s a good suggestion, but I feel the example gets harder to understand using Iterators since we can’t simply unwrap using `?` as we do in the rest of the examples.

`results` is of type: `Vec<Result<Result<(u64, u64), Box, JoinError>>` which is a nested result making the iterator version pretty difficult to understand for people not intimately familiar with functional style programming.

We might as well use `try_fold` instead of `try_for_each` if we were to do this operation using a functional style so the code would look something like this:

“`
let (total_ones, total_zeros) =
results
.into_iter()
.flatten()
.try_fold((0, 0), |(total_ones, total_zeros), res| {
res.map(|(ones, zeros)| (total_ones + ones, total_zeros + zeros))
})?;
“`

I feel it makes things more complicated than it needs to be in an example where the main focus is on keeping the code easy to read for a wide audience without really giving a lot of benefit in return 🙂

What’s wrong with `try_for_each`?

The difference is that the code you write in a main function with `#[tokio::main]` is wrapped in an async block instead of put in a function called `app` but the end result is pretty similar.

I posted the output from the macro in another answer below but it doesn’t look pretty in the comments section here. If you want to check it out for yourself install `cargo install cargo-expand` and run `cargo expand` in the root of a project with the example code in `main.rs`. You’ll see what it expands into.

“‘
async fn our_async_program() -> Result {
future::ok(“Hello world”.to_string()).await
}
“‘
Since the compiler can infer the rest in this case. Thanks for pointing it out.