Merge pull request #4238 from ormai/main

Fix typos in chapter 17

Author: chriskrycho

src/ch17-04-streams.md

@@ -18,7 +18,7 @@ channel receiver. The first difference is time: iterators are synchronous, while
 the channel receiver is asynchronous. The second is the API. When working
 directly with `Iterator`, we call its synchronous `next` method. With the
 `trpl::Receiver` stream in particular, we called an asynchronous `recv` method
-instead. Otherwise, these APIs otherwise feel very similar, and that similarity
+instead. Otherwise, these APIs feel very similar, and that similarity
 isn’t a coincidence. A stream is like an asynchronous form of iteration. Whereas
 the `trpl::Receiver` specifically waits to receive messages, though, the
 general-purpose stream API is much broader: it provides the next item the
@@ -123,7 +123,7 @@ we can do that _is_ unique to streams.
 
 Many concepts are naturally represented as streams: items becoming available in
 a queue, chunks of data being pulled incrementally from the filesystem when the
-full data set is too large for the computer’s , or data arriving over the
+full data set is too large for the computer’s memory, or data arriving over the
 network over time. Because streams are futures, we can use them with any other
 kind of future and combine them in interesting ways. For example, we can batch
 up events to avoid triggering too many network calls, set timeouts on sequences

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

@@ -167,7 +167,7 @@ function. The signature for `join_all` requires that the types of the items in
 the collection all implement the `Future` trait, and `Box<T>` implements
 `Future` only if the `T` it wraps is a future that implements the `Unpin` trait.
 
-That’s a lot to absorb! To really understand it, let’s we dive a little further
+That’s a lot to absorb! To really understand it, let’s dive a little further
 into how the `Future` trait actually works, in particular around _pinning_.
 
 Look again at the definition of the `Future` trait:
@@ -189,7 +189,7 @@ knows when to check any given future while still being lazy. Again, the details
 of how that works are beyond the scope of this chapter, and you generally only
 need to think about this when writing a custom `Future` implementation. We’ll
 focus instead on the type for `self`, as this is the first time we’ve seen a
-method where `self` has a type annotation. A type annotation for `self` is works
+method where `self` has a type annotation. A type annotation for `self` works
 like type annotations for other function parameters, but with two key
 differences: