An example of hand-written coroutines 147 poll them to completion one by one in the current design, the futures would not progress concurrently. Let that sink in for a moment. Languages such as Java Script start the operation when the coroutine is created, so there is no “one way” to do this. Every time you encounter a coroutine implementation, you should find out whether they're lazy or eager since this impacts how you program with them. Even though we could make our future eager in this case, we really shouldn't. Since programmers in Rust expect futures to be lazy, they might depend on nothing happening before you call poll on them, and there may be unexpected side effects if the futures you write behave differently. Now, when you read that Rust's futures are always lazy, a claim that I see very often, it refers to the compiler-generated state machines resulting from using async/await. As we'll see later, when your async functions are rewritten by the compiler, they're constructed in a way so that nothing you write in the body of an async function will execute before the first call to Future::poll. Okay, so we've covered the Future trait and the leaf future we named Http Get Future. The next step is to create a task that we can stop and resume at predefined points. Creating coroutines We'll continue to build our knowledge and understanding from the ground up. The first thing we'll do is create a task that we can stop and resume by modeling it as a state machine by hand. Once we've done that, we'll take a look at how this way of modeling pausable tasks enables us to write a syntax much like async/await and rely on code transformations to create these state machines instead of writing them by hand. We'll create a simple program that does the following: 1. Prints a message when our pausable task is starting. 2. Makes a GET request to our delayserver. 3. Waits for the GET request. 4. Prints the response from the server. 5. Makes a second GET request to our delayserver. 6. Waits for the second response from the server. 7. Prints the response from the server. 8. Exits the program. In addition, we'll execute our program by calling Future::poll on our hand-crafted coroutine as many times as required to run it to completion. There's no runtime, reactor, or executor yet since we'll cover those in the next chapter.