fix: Found and fixed some spelling errors.

README.md

@@ -56,7 +56,7 @@ in the `Poll` method and a possible race condition. See #2 for more details.
 
 **2020-04-13:** Added a "bonus section" to the [Implementing Futures chapter](https://cfsamson.github.io/books-futures-explained/6_future_example.html) where we avoid using `thread::park` and instead show how we
 can use a `Condvar` and a `Mutex` to create a proper `Parker`. Updated the [Finished Example](https://cfsamson.github.io/books-futures-explained/8_finished_example.html) to reflect these changes. Unfortunately, this led us
-a few lines over my initial promis of keeping the example below 200 LOC but the I think the inclusion
+a few lines over my initial promise of keeping the example below 200 LOC but the I think the inclusion
 is worth it.
 
 **2020-12-21:** Rewrote the "Runtimes" paragraph of chapter 2 adding a useful model to understand

scrapped_chapters/5_reactor_executor.md

@@ -26,7 +26,7 @@ I'll re-iterate the most important parts here.
 
 1. **A reactor**
     - handles some kind of event queue
-    - has the responsibility of respoonding to events
+    - has the responsibility of responding to events
 2. **An executor**
     - Often has a scheduler
     - Holds a set of suspended tasks, and has the responsibility of resuming
@@ -34,7 +34,7 @@ I'll re-iterate the most important parts here.
 3. **The concept of a task**
     - A set of operations that can be stopped half way and resumed later on
 
-This kind of pattern common outside of Rust as well, but it's especially popular in Rust due to how well it alignes with the API provided by Rusts standard library. This model separates concerns between handling and scheduling tasks, and queing and responding to I/O events.
+This kind of pattern common outside of Rust as well, but it's especially popular in Rust due to how well it aligns with the API provided by Rusts standard library. This model separates concerns between handling and scheduling tasks, and queuing and responding to I/O events.
 
 ## The Reactor
 
@@ -65,7 +65,7 @@ These operations can spawn new leaf futures themselves.
 
 The executors task is to take one or more futures and run them to completion.
 
-The first thing an `executor` does when it get's a `Future` is polling it.
+The first thing an `executor` does when it gets a `Future` is polling it.
 
 **When polled one of three things can happen:**
 

scrapped_chapters/introduction.md

@@ -40,7 +40,7 @@ There were other issues as well, but the lack of ergonomics was one of the major
 
 #### Futures 0.3
 
-This is the current iteration over `Futures` and the one we'll use in our examples. This iteration solved a lot of the problems with 1.0, especially concerning ergonimics.
+This is the current iteration over `Futures` and the one we'll use in our examples. This iteration solved a lot of the problems with 1.0, especially concerning ergonomics.
 
 The `async/await` syntax was designed in tandem with `Futures 3.0` and provides a much more ergonomic way to work with `Futures`:
 

src/2_a_mental_model_for_futures.md

@@ -2,7 +2,7 @@
 
 The main goal in this part is to build a high level
 mental model of how the different pieces we read about in the previous chapter
-works toghether. I hope this will make it easier to understand what we just read
+works together. I hope this will make it easier to understand what we just read
 about in the previous chapter and also explain why we take a deep dive into topics
 like trait objects and generators in the next few chapters.
 

src/6_future_example.md

@@ -677,7 +677,7 @@ The last point is relevant when we move on the the last paragraph.
 > also look at ways to fix it. For now, just make a note of it so you're aware
 > of the problem.
 
-## Async/Await and concurrecy
+## Async/Await and concurrency
 
 The `async` keyword can be used on functions as in `async fn(...)` or on a
 block as in `async { ... }`. Both will turn your function, or block, into a

src/conclusion.md

@@ -30,7 +30,7 @@ thing in a slightly different way to get some inspiration.
 * Do you want to pass around a reference to this information using an `Arc`?
 * Do you want to make a global `Reactor` so it can be accessed from anywhere?
 
-### Building a better exectuor
+### Building a better executor
 
 Right now, we can only run one and one future only. Most runtimes has a `spawn`
 function which let's you start off a future and `await` it later so you