My inclination is to put the new chapter immediately after the Fearless Concurrency chapter. That will have given people a lot of the relevant mental machinery for thinking about concurrency in general, and then the async/await stuff can build on it by saying, roughly, “Okay, but threads are expensive, etc. etc. etc.” and use that as a transition into motivation for async/await.

That does also raise the question of how we should title it! It’s even more concurrency. 😂

WebSockets are relatively lightweight from a protocol POV and there are a couple solid Rust libraries for them. I wonder if they might be a good target for showing some of the interactions and coordination you want t

• Chat server: This one is relatively obvious in that it is the canonical example and motivation for WebSockets themselves, and building a chat client is actually pretty neat: being able to have two browser windows up next to each other and see the messages appear back and forth in basically-real-time is great. The downside I see here is that it does not show a lot of the coordination aspects—basically just shutdown for closing the socket, and having both sender and receiver sides.

• Live reload server: This is a little less obvious but I think might actually work better. It would show async coordination between file events (using notify or maybe watchexec), the web server (probably using Axum? But I am very open to something else, too), and a WebSocket connection (fastwebsockets seems nice?). It also basically covers everything that the chat server does, I think.

  I have been thinking about this one for a while (I was interested in it at a personal level, never having built one), and I think it might be just small enough to manage.

For either of these, or indeed anything which has a browser UI attached, I think it will behoove us to supply a Git repo (perhaps a GitHub “template”-style repo) which people can use as the starting point for their implementation, which supplies (minimal) pre-baked HTML, CSS, and JS/TS (already compiled, or with a known-good and verified-by-CI-all-the-time build) that makes it easy for people to just focus on the Rust part. The client-side code there can be fairly minimal.

Thoughts, @carols10cents?

Re: green threads--

There used to be a discussion of green threads in the book, but apparently we messed it up, so I removed it. 🤷🏻‍♀️

If it makes sense to mention it, I'm not opposed to putting it back (with an actually correct definition, of course!)