Ch. 17: minor typos and link reference (#4286)

Co-authored-by: Chris Krycho <hello@chriskrycho.com>

Author: rickrain

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

@@ -131,7 +131,7 @@ Notice that Rust’s `await` keyword goes _after_ the expression you’re awaiti
 not before it. That is, it’s a _postfix_ keyword. This may differ from what
 you’re used to if you’ve used `async` in other languages, but in Rust it makes
 chains of methods much nicer to work with. As a result, we can change the body
-of `page_url_for` to chain the `trpl::get` and `text` function calls together
+of `page_title` to chain the `trpl::get` and `text` function calls together
 with `await` between them, as shown in Listing 17-2.
 
 <Listing number="17-2" file-name="src/main.rs" caption="Chaining with the `await` keyword">
@@ -319,7 +319,7 @@ function in `main` to set up a runtime and run the future returned by the
 
 > Note: Some runtimes provide macros so you _can_ write an async `main`
 > function. Those macros rewrite `async fn main() { ... }` to be a normal `fn
-> main`, which does the same thing we did by hand in Listing 17-5: call a
+> main`, which does the same thing we did by hand in Listing 17-4: call a
 > function that runs a future to completion the way `trpl::run` does.
 
 Now let’s put these pieces together and see how we can write concurrent code.
@@ -364,10 +364,11 @@ enum Either<A, B> {
 }
 ```
 
-The `race` function returns `Left` with that future’s output if the first
-argument wins, and `Right` with the second future argument’s output if _that_
-one wins. This matches the order the arguments appear in when calling the
-function: the first argument is to the left of the second argument.
+The `race` function returns `Left` with the output from the first future
+argument it finishes first, or `Right` with the output of the second future
+argument if that one finishes first. This matches the order the arguments appear
+in when calling the function: the first argument is to the left of the second
+argument.
 
 We also update `page_title` to return the same URL passed in. That way, if
 the page that returns first does not have a `<title>` we can resolve, we can

src/ch17-02-concurrency-with-async.md

@@ -308,7 +308,7 @@ flow—exactly what we’re trying _not_ to do.
 With the updated code in Listing 17-11, the messages get printed at
 500-millisecond intervals, rather than all in a rush after 2 seconds.
 
-The program still never exits, though, because of the way `while let` loop
+The program still never exits, though, because of the way the `while let` loop
 interacts with `trpl::join`:
 
 - The future returned from `trpl::join` completes only once _both_ futures

src/ch17-03-more-futures.md

@@ -27,7 +27,7 @@ join on _all_ of them. The `trpl::join_all` function accepts any type that
 implements the `Iterator` trait, which you learned about back in [The Iterator
 Trait and the `next` Method][iterator-trait]<!-- ignore --> Chapter 13, so
 it seems like just the ticket. Let’s try putting our futures in a vector and
-replacing `join!` with `join_all` as show in Listing 17-15.
+replacing `join!` with `join_all` as shown in Listing 17-15.
 
 <Listing  number="17-15" caption="Storing anonymous futures in a vector and calling `join_all`">
 
@@ -592,6 +592,6 @@ to consider first, though:
   with any collection of futures.)
 
 [dyn]: ch12-03-improving-error-handling-and-modularity.html
-[enum-alt]: ch12-03-improving-error-handling-and-modularity.html#returning-errors-from-the-run-function
+[enum-alt]: ch08-01-vectors.html#using-an-enum-to-store-multiple-types
 [async-program]: ch17-01-futures-and-syntax.html#our-first-async-program
 [iterator-trait]: ch13-02-iterators.html#the-iterator-trait-and-the-next-method