Write chapter about async Rust

[mgeisler]

We should write a chapter about async Rust. This would be a good alternative to the Android part on Day 4. A possible agenda could look like this:

• Introductory Example
• Terminology
• Futures
• await
• Runtimes
• Spawning
• IO-Compatible Cunctions

[djmitche]

I just looked through my Rust books, and most don't actually cover async/await. The one that does is Rust for Rustaceans. Its ordering is similar to what's given above: it starts with polling, then futures, then a long section on pinning, then wakers and context, and finally spawning and tasks. I don't think that's appropriate for an introductory course, especially for the very end of one -- nobody's going to have headspace left to grok Pin at the end of day 4.

Instead, I think we should go in the opposite order, and start with an async fn with some .await's in it. From there we can drill down a little into futures and executors. A brief "how does it work" can cover polling, pin, and context/wakers, with acknowledgement that the coverage is incomplete. Finally, we can talk a bit about a few of the features corresponding to those in the thread concurrency chapter, as long as that's not too specific to any one runtime.

What do you think? I've gotten a start on this and I'll put up a PR shortly.

[rbehjati]

I totally agree that for an introductory course it is better to avoid going into the details of pinning and polling. I think we could base the course materials on the first few chapters of https://rust-lang.github.io/async-book/, possibly, sections 1, 3, 4 and 6. But I have only skimmed through the book. I think that is more or less what you are suggesting :)

[mgeisler]

nobody's going to have headspace left to grok Pin at the end of day 4.

it is better to avoid going into the details of pinning and polling

Yeah, I agree with that — I don't feel I fully understand pinning myself, but that doesn't stop me from writing async Rust code 😄

When writing this, be careful to avoid forward references. That is, try to apply a principle of showing things in a way that builds upon previously shown content. I didn't do that very strictly in the main course and I would like to start reorganizing it to follow this principle. Since this is new material, you have the chance of applying it from the beginning.

As for this being an introduction or not: I imagine you have a full day, so 5-6 hours to play with. I hope that is enough to let people get their hands dirty with some actual code. Maybe it could be useful to find a nice exercise and then work backwards to figure out what needs to be covered for people to solve it. I bet that pinning won't be super important then.

[rbehjati]

When writing this, be careful to avoid forward references.

Very good point. Will keep this in mind.

As for this being an introduction or not: I imagine you have a full day, so 5-6 hours to play with.

I was thinking of half a day. Concurrency in the morning as before, then Async in the afternoon. In any case pinning is too complicated :)

[mgeisler]

As for this being an introduction or not: I imagine you have a full day, so 5-6 hours to play with.

I was thinking of half a day. Concurrency in the morning as before, then Async in the afternoon. In any case pinning is too complicated :)

Yes, that would make sense if the material is light and fits. I'm thinking it won't actually fit and so we should prepare to use the full day.

That would match the current thinking of creating small spin-off courses for special topics. That was touched upon here.

But we'll see as the material gets written

[mgeisler]

Done, thanks to the great work of @djmitche, @rbehjati, and @sakex!