An example of hand-written coroutines 153 Schedule other tasks Schedule other tasks Schedule other tasks Schedule other tasks HTTP/1. 1 200 OK content-length: 11 connection: close content-type: text/plain; charset=utf-8 date: Tue, 24 Oct 2023 20:39:13 GMT Hello World2 By looking at the printouts, you can get an idea of the program flow. 1. First, we see Program starting, which executes at the start of our coroutine. 2. We then see that we immediately move on to the FIRST POLL-START OPERATION message that we only print when the future returned from our HTTP client is polled the first time. 3. Next, we can see that we're back in our main function, and at this point, we could theoretically go ahead and run other tasks if we had any 4. Every 100 ms, we check if the task is finished and get the same message telling us that we can schedule other tasks 5. Then, after roughly 600 milliseconds, we receive a response that's printed out 6. We repeat the process once more until we receive and print out the second response from the server Congratulations, you've now created a task that can be paused and resumed at different points, allowing it to be in progress. Who on earth wants to write code like this to accomplish a simple task? The answer is no one! Y es, it's a bit bombastic, but I dare guess that very few programmers prefer writing a 55-line state machine when you compare it to the 7 lines of normal sequential code you' d have to write to accomplish the same thing. If we recall the goals of most userland abstractions over concurrent operations, we'll see that this way of doing it only checks one of the three boxes that we're aiming for: Efficient Expressive Easy to use and hard to misuse