diff --git a/src/ch17-05-traits-for-async.md b/src/ch17-05-traits-for-async.md
index 1b7b23b7d8..e3819d9a49 100644
--- a/src/ch17-05-traits-for-async.md
+++ b/src/ch17-05-traits-for-async.md
@@ -92,9 +92,9 @@ loop {
 ```
 
 If Rust compiled it to exactly that code, though, every `await` would be
-blocking—exactly the opposite of what we were going for! Instead, Rust needs
-makes sure that the loop can hand off control to something which can pause work
-on this future and work on other futures and check this one again later. That
+blocking—exactly the opposite of what we were going for! Instead, Rust makes
+sure that the loop can hand off control to something which can pause work on
+this future and work on other futures and check this one again later. That
 “something” is an async runtime, and this scheduling and coordination work is
 one of the main jobs for a runtime.
 
@@ -153,10 +153,10 @@ future with `await` pins the future implicitly. That’s why we don’t need to
 
 However, we’re not directly awaiting a future here. Instead, we construct a new
 future, `JoinAll`, by passing a collection of futures to the `join_all`
-function. The signature for `join_all` produces requires that the type of the
-items in the collection all implement the `Future` trait, and `Box<T>` only
-implements `Future` if the `T` that it wraps is a future which implements the
-`Unpin` trait.
+function. The signature for `join_all` requires that the type of the items in
+the collection all implement the `Future` trait, and `Box<T>` only implements
+`Future` if the `T` that it wraps is a future which implements the `Unpin`
+trait.
 
 That’s a lot! But we can understand it, if we dive a little further into how the
 `Future` type actually works, in particular around *pinning*.