diff --git a/src/1_futures_in_rust.md b/src/1_futures_in_rust.md
index b93d2cf..1eaf8a8 100644
--- a/src/1_futures_in_rust.md
+++ b/src/1_futures_in_rust.md
@@ -165,7 +165,7 @@ future through the `Future` trait.
 the `async` and `await` keywords.
 3. A defined interface to wake up a suspended task through the `Waker` type.
 
-That's really what Rusts standard library does. As you see there is no definition
+That's really what Rust's standard library does. As you see there is no definition
 of non-blocking I/O, how these tasks are created, or how they're run.
 
 ## I/O vs CPU intensive tasks
@@ -235,7 +235,7 @@ Take a break or a cup of coffee and get ready as we go for a deep dive in the ne
 
 If you find the concepts of concurrency and async programming confusing in
 general, I know where you're coming from and I have written some resources to
-try to give a high-level overview that will make it easier to learn Rusts
+try to give a high-level overview that will make it easier to learn Rust's
 Futures afterwards:
 
 * [Async Basics - The difference between concurrency and parallelism](https://cfsamson.github.io/book-exploring-async-basics/1_concurrent_vs_parallel.html)
diff --git a/src/4_generators_async_await.md b/src/4_generators_async_await.md
index a215a27..154c964 100644
--- a/src/4_generators_async_await.md
+++ b/src/4_generators_async_await.md
@@ -4,7 +4,7 @@
 >
 >- Understand how the async/await syntax works under the hood
 >- See first hand why we need `Pin`
->- Understand what makes Rusts async model very memory efficient
+>- Understand what makes Rust's async model very memory efficient
 >
 >The motivation for `Generator`s can be found in [RFC#2033][rfc2033]. It's very
 >well written and I can recommend reading through it (it talks as much about
@@ -301,7 +301,7 @@ impl Generator for GeneratorA {
 If you try to compile this you'll get an error (just try it yourself by pressing play).
 
 What is the lifetime of `&String`. It's not the same as the lifetime of `Self`. It's not `static`.
-Turns out that it's not possible for us in Rusts syntax to describe this lifetime, which means, that
+Turns out that it's not possible for us in Rust's syntax to describe this lifetime, which means, that
 to make this work, we'll have to let the compiler know that _we_ control this correctly ourselves.
 
 That means turning to unsafe.
diff --git a/src/5_pin.md b/src/5_pin.md
index 5824c27..a2bd592 100644
--- a/src/5_pin.md
+++ b/src/5_pin.md
@@ -25,7 +25,7 @@ to govern the rules that need to apply for types which implement `!Unpin`.
 Yep, you're right, that's double negation right there. `!Unpin` means
 "not-un-pin".
 
-> _This naming scheme is one of Rusts safety features where it deliberately
+> _This naming scheme is one of Rust's safety features where it deliberately
 > tests if you're too tired to safely implement a type with this marker. If
 > you're starting to get confused, or even angry, by `!Unpin` it's a good sign
 > that it's time to lay down the work and start over tomorrow with a fresh mind._