Ch. 17: fresh-eyes edits

Or: what happens when you reread your own work after a couple months
away from it!

src/ch17-01-futures-and-syntax.md

@@ -111,8 +111,8 @@ allows Rust to avoid running async code until it’s actually needed.
 > using `thread::spawn` in [Creating a New Thread with
 > spawn][thread-spawn]<!--ignore-->, where the closure we passed to another
 > thread started running immediately. It’s also different from how many other
-> languages approach async. But it’s important for Rust, and we’ll see why
-> later.
+> languages approach async. But it’s important for Rust to be able to provide
+> its performance guarantees, just as it is with iterators.
 
 Once we have `response_text`, we can parse it into an instance of the `Html`
 type using `Html::parse`. Instead of a raw string, we now have a data type we
@@ -315,7 +315,7 @@ function back in Listing 17-3. If `main` were an async function, something else
 would need to manage the state machine for whatever future `main` returned, but
 `main` is the starting point for the program! Instead, we called the `trpl::run`
 function in `main` to set up a runtime and run the future returned by the
-`async` block until it returns `Ready`.
+`async` block until it is done.
 
 > Note: Some runtimes provide macros so you _can_ write an async `main`
 > function. Those macros rewrite `async fn main() { ... }` to be a normal `fn

src/ch17-05-traits-for-async.md

@@ -300,16 +300,15 @@ itself cannot move, because it is still pinned.
 </figure>
 
 However, most types are perfectly safe to move around, even if they happen to be
-behind a `Pin` pointer. We only need to think about pinning when items have
-internal references. Primitive values such as numbers and Booleans are safe
-since they obviously don’t have any internal references, so they’re obviously
-safe. Neither do most types you normally work with in Rust. You can move around
-a `Vec`, for example, without worrying. Given only what we have seen so far, if
-you have a `Pin<Vec<String>>`, you’d have to do everything via the safe but
-restrictive APIs provided by `Pin`, even though a `Vec<String>` is always safe
-to move if there are no other references to it. We need a way to tell the
-compiler that it’s fine to move items around in cases like this—and there’s
-where `Unpin` comes into play.
+behind a `Pin` wrapper. We only need to think about pinning when items have
+internal references. Primitive values such as numbers and Booleans obviously
+don’t have any internal references, so they’re safe. Neither do most types you
+normally work with in Rust. You can move around a `Vec`, for example, without
+worrying. Given only what we have seen so far, if you have a `Pin<Vec<String>>`,
+you’d have to do everything via the safe but restrictive APIs provided by `Pin`,
+even though a `Vec<String>` is always safe to move if there are no other
+references to it. We need a way to tell the compiler that it’s fine to move
+items around in cases like this—and there’s where `Unpin` comes into play.
 
 `Unpin` is a marker trait, similar to the `Send` and `Sync` traits we saw in
 Chapter 16, and thus has no functionality of its own. Marker traits exist only