unsafe-deep-dive: remove weasel words

src/unsafe-deep-dive/case-studies/intrusive-linked-list.md

@@ -3,7 +3,7 @@
 > Current as of tokio v1.48.0
 
 The Tokio project maintains an [intrusive linked list implementation][ill] that
-demonstrates many use cases of `unsafe` and a number of types and traits from
+demonstrates several use cases of `unsafe` and a number of types and traits from
 Rust's unsafe ecosystem, including `cell::UnsafeCell`, `mem::ManuallyDrop`,
 [pinning](../pinning/what-pinning-is.md), and unsafe traits.
 
@@ -99,7 +99,7 @@ struct PointersInner<T> {
 ## Remarks
 
 Understanding the whole implementation will take some time, but it's a rewarding
-experience. The code demonstrates composing many parts of unsafe Rust's
+experience. The code demonstrates composing multiple parts of unsafe Rust's
 ecosystem into a workable, high performance data structure. Enjoy exploring!
 
 [ill]: https://docs.rs/tokio/1.48.0/src/tokio/util/linked_list.rs.html

src/unsafe-deep-dive/introduction/characteristics-of-unsafe-rust/sometimes-necessary.md

@@ -23,7 +23,7 @@ block.”
 
 Optional:
 
-“Working with the external environment often involves sharing memory. The
+“Working with the external environment frequently involves sharing memory. The
 interface that computers provide is a memory address (a pointer).”
 
 “Here's an example that asks the Linux kernel to write to memory that we

src/unsafe-deep-dive/introduction/warm-up/unsafe-fn.md

@@ -40,14 +40,14 @@ responsibility for guarding against invalid inputs, or we can shift that
 responsibility to the caller with the unsafe keyword.”
 
 “The first path is a difficult one. We’re accepting a generic type T, which is
-all possible types that implement Sized. That’s a lot of types!
+all possible types that implement Sized. That is a vast number of types!
 
 “Therefore, the second path makes more sense.
 
 _Extra content (time permitting)_
 
 “By the way, if you’re interested in the details of pointers and what the rules
-of converting them to references are, the standard library has a lot of useful
+of converting them to references are, the standard library has many useful
 documentation. You should also look into the source code of many of the methods
 on std::pointer.
 

src/unsafe-deep-dive/introduction/warm-up/unsafe-impl.md

@@ -20,20 +20,20 @@ impl Sync for LogicalClock {}
 “Before we take a look at the code, we should double check that everyone knows
 what a trait is. Is anyone able to explain traits for the rest of the class?
 
-- “Traits are often described as a way to create shared behavior. Thinking about
-  traits as shared behavior focuses on the syntax of methods and their
+- “Traits are commonly described as a way to create shared behavior. Thinking
+  about traits as shared behavior focuses on the syntax of methods and their
   signatures.
 - “There’s also a deeper way to think of traits: as sets of requirements. This
   emphasizes the shared semantics of the implementing types.
 
 “Can anyone explain what the `Send` and `Sync` traits are?
 
 - If no
-  - “Send and Sync relate to concurrency. There are many details, but broadly
-    speaking, Send types can be shared between threads by value. Sync types must
-    be shared by reference.
-  - There are many rules to follow to ensure that it’s safe to share data across
-    thread boundaries. Those rules cannot be checked by the compiler, and
+  - “Send and Sync relate to concurrency. There are numerous details, but
+    broadly speaking, Send types can be shared between threads by value. Sync
+    types must be shared by reference.
+  - There are strict rules to follow to ensure that it’s safe to share data
+    across thread boundaries. Those rules cannot be checked by the compiler, and
     therefore the code author must take responsibility for upholding them.
   - Arc implements Send and Sync, therefore it’s safe for our clock to as well.
   - It may be useful to point out that the word _atomic_ has the meaning of