diff --git a/src/conclusion.md b/src/conclusion.md
index 009735a..bc895ee 100644
--- a/src/conclusion.md
+++ b/src/conclusion.md
@@ -1,9 +1,9 @@
 # Conclusion and exercises
 
-Congratulations. Good job! If you got this far you must have stayed with me
+Congratulations. Good job! If you got this far, you must have stayed with me
 all the way. I hope you enjoyed the ride!
 
-Remember that you call always leave feedback, suggest improvements or ask questions
+Remember that you can always leave feedback, suggest improvements or ask questions
 in the [issue_tracker](https://github.com/cfsamson/books-futures-explained/issues) for this book.
 I'll try my best to respond to each one of them.
 
@@ -14,7 +14,7 @@ Until next time!
 ## Reader exercises
 
 So our implementation has taken some obvious shortcuts and could use some improvement.
-Actually digging into the code and try things yourself is a good way to learn. Here are
+Actually, digging into the code and trying things yourself is a good way to learn. Here are
 some good exercises if you want to explore more:
 
 ### Avoid wrapping the whole `Reactor` in a mutex and pass it around
@@ -32,16 +32,16 @@ thing in a slightly different way to get some inspiration.
 
 ### Building a better executor
 
-Right now, we can only run one and one future only. Most runtimes has a `spawn`
+Right now, we can only run one and one future only. Most runtimes have a `spawn`
 function which let's you start off a future and `await` it later so you
 can run multiple futures concurrently.
 
 As I suggested in the start of this book, visiting [@stjepan'sblog series about implementing your own executors](https://web.archive.org/web/20200207092849/https://stjepang.github.io/2020/01/31/build-your-own-executor.html)
-is the place I would start and take it from there. You could further examine the source code of [smol - A small and fast async runtime](https://github.com/smol-rs/smol) wich is a good project to learn from.
+is the place I would start and take it from there. You could further examine the source code of [smol - A small and fast async runtime](https://github.com/smol-rs/smol) which is a good project to learn from.
 
-### Create an unique Id for each task
+### Create a unique Id for each task
 
-As we discussed in the end of the main example. What happens if the user pass in
+As we discussed at the end of the main example. What happens if the user pass in
 the same Id for both events?
 
 ```rust, ignore
@@ -49,14 +49,14 @@ let future1 = Task::new(reactor.clone(), 1, 1);
 let future2 = Task::new(reactor.clone(), 2, 1);
 ```
 
-Right now it will deadlock since our `poll` method thinks the first poll of
+Right now, it will deadlock since our `poll` method thinks the first poll of
 `future2` is `future1` getting polled again and swaps out the waker with the
 one from `future2`. This waker never gets called since the task is never
 registered.
 
 It's probably a bad idea to expose the user to this behavior, so we
-should have a unique Id for each task which we use internally. There are a
-many ways to solve this. Below is two suggestions to get going:
+should have a unique Id for each task which we use internally. There are many ways to solve this. 
+Below is two suggestions to get going:
 
 1. Let the reactor have a `usize` which is incremented on every task creation
 2. Use a crate like `Guid` to generate an unique Id for each task
@@ -66,7 +66,7 @@ many ways to solve this. Below is two suggestions to get going:
 There are many great resources. In addition to the RFCs and articles I've already
 linked to in the book, here are some of my suggestions:
 
-[The official Asyc book](https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html)
+[The official Async book](https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html)
 
 [Tokio tutorial](https://tokio.rs/tokio/tutorial)