Use “asynchronous programming” or “async”, not “async-await”

src/ch16-01-threads.md

@@ -26,12 +26,12 @@ a code structure that is different from that in programs running in a single
 thread.
 
 Programming languages implement threads in a few different ways, and many
-operating systems provide an API the language can call for creating new
-threads. The Rust standard library uses a *1:1* model of thread implementation,
-whereby a program uses one operating system thread per one language thread.
-There are crates that implement other models of threading that make different
-tradeoffs to the 1:1 model. (Rust’s async-await system, which we will see in the
-next chapter, provides another approach to concurrency as well.)
+operating systems provide an API the language can call for creating new threads.
+The Rust standard library uses a *1:1* model of thread implementation, whereby a
+program uses one operating system thread per one language thread. There are
+crates that implement other models of threading that make different tradeoffs to
+the 1:1 model. (Rust’s async system, which we will see in the next chapter,
+provides another approach to concurrency as well.)
 
 ### Creating a New Thread with `spawn`
 

src/ch17-00-async-await.md

@@ -1,20 +1,20 @@
 ## Async and Await
 
 In Chapter 16, we saw one of Rust’s approaches to concurrency: using threads.
-Since Rust 1.39, there has been another option for concurrency: the async-await
-model.
+Since Rust 1.39, there has been another option for concurrency: asynchronous
+programming, or *async*.
 
 In the rest of chapter, we will:
 
 * see how to use Rust’s `async` and `.await` syntax
-* explore how to use the async-await model to solve some of the same challenges
-  we looked at in Chapter 16
-* look at how multithreading and async-await provide complementary solutions,
-  which you can even use together in many cases
+* explore how to use the async model to solve some of the same challenges we
+  looked at in Chapter 16
+* look at how multithreading and async provide complementary solutions, which
+  you can even use together in many cases
 
-First, though, let’s explore what async-await gives us.
+First, though, let’s explore what async gives us.
 
-### Why async-await
+### Why Async?
 
 Many operations we ask the computer to do can take a while to finish. For
 example, if you used a video editor to create a video of a family celebration,
@@ -49,12 +49,12 @@ On a machine with multiple CPU cores, we can actually do work in parallel. One
 core can be doing one thing while another core does something completely
 unrelated, and those actually happen at the same time. On a machine with a
 single CPU core, the CPU can only do one operation at a time, but we can still
-have concurrency. Using tools like threads, processes, and async-await, the
-computer can pause one activity and switch to others before eventually cycling
-back to that first activity again. So all parallel operations are also
-concurrent, but not all concurrent operations happen in parallel!
+have concurrency. Using tools like threads, processes, and async, the computer
+can pause one activity and switch to others before eventually cycling back to
+that first activity again. So all parallel operations are also concurrent, but
+not all concurrent operations happen in parallel!
 
-> Note: When working with async-await in Rust, we need to think in terms of
+> Note: When working with async in Rust, we need to think in terms of
 > *concurrency*. Depending on the hardware, the operating system, and the async
 > runtime we are using, that concurrency may use some degree of parallelism
 > under the hood, or it may not. More about async runtimes in a later section!
@@ -81,9 +81,9 @@ In both of these cases, it might be useful for *your program* to participate in
 the same kind of concurrency the computer is providing for the rest of the
 system. One way to do this is the approach we saw last chapter: using threads,
 which are provided and managed by the operating system. Another way to get
-access to concurrency is using language-specific capabilities—like async-await.
+access to concurrency is using language-specific capabilities—like async.
 
-A big difference between the cooking analogy and Rust’s async-await model for
+A big difference between the cooking analogy and Rust’s async model for
 concurrency is that in the cooking example, the cook makes the decision about
-when to switch tasks. In Rust’s async-await model, the tasks are in control of
-that. To see how, let’s look at how Rust actually uses async-await.
+when to switch tasks. In Rust’s async model, the tasks are in control of that.
+To see how, let’s look at how Rust actually uses async.

src/ch17-01-tasks.md

@@ -1,4 +1,4 @@
-## Futures and the Async-Await Syntax
+## Futures and the Async Syntax
 
 ### Tasks
 
@@ -11,23 +11,23 @@ multiple threads. While mainstream desktop and mobile operating systems have all
 had threading for many years, many embedded operating systems used on
 microcontrollers do not.
 
-The async-await model provides a different, complementary set of tradeoffs. In
+The async model provides a different, complementary set of tradeoffs. In
 
 <!-- TODO: the following paragraph is not where it needs to be structurally. -->
 
-In the async-await model, concurrent operations do not require their own
-threads. Instead, they can run on *tasks*. A task is a bit like a thread, but
-instead of being managed by the operating system, it is managed by a runtime.
+In the async model, concurrent operations do not require their own threads.
+Instead, they can run on *tasks*. A task is a bit like a thread, but instead of
+being managed by the operating system, it is managed by a runtime.
 
 <!-- TODO: connective tissue as it were. -->
 
 ###
 
-Like many other languages with first-class support for the async-await
-programming model, Rust uses the `async` and `await` keywords—though with some
-important differences from other languages like C# or JavaScript. Blocks and
-functions can be marked `async`, and you can wait on the result of an `async`
-function or block to resolve using the `await` keyword.
+Like many other languages with first-class support for the async programming
+model, Rust uses the `async` and `await` keywords—though with some important
+differences from other languages like C# or JavaScript. Blocks and functions can
+be marked `async`, and you can wait on the result of an `async` function or
+block to resolve using the `await` keyword.
 
 Let’s write our first async function:
 
@@ -194,10 +194,10 @@ The other thing to notice here is that futures in Rust are *lazy*. They do not
 do anything until you explicitly ask them to—whether by calling `poll` or by
 using `.await` to do so. This is different from the behavior we saw when using
 `thread::spawn` in the previous chapter, and it is different from how many other
-languages approach async-await. This allows Rust to avoid running async code
-unless it is actually needed, and supports some of the memory safety features
-Rust brings to async-await. (The details are beyond the scope of this book, but
-are well worth digging into.)
+languages approach async. This allows Rust to avoid running async code unless it
+is actually needed, and supports some of the memory safety features Rust brings
+to async. (The details are beyond the scope of this book, but are well worth
+digging into.)
 
 ### Running Async Code
 
@@ -241,7 +241,7 @@ Hello, async!
 ```
 
 Now, that’s a lot of work to just print a string, but we have laid some key
-foundations for working with async-await in Rust! Now that you know the basics
-of how futures work, and the
+foundations for working with async in Rust! Now that you know the basics of how
+futures work, and the
 
 [impl-trait]: ch10-02-traits.html#traits-as-parameters

src/ch17-02.md

@@ -10,12 +10,12 @@ widely used async runtime, especially (but not only!) for web applications.
 > suitable for your purposes, so this is not at all saying Tokio is better than
 > the alternatives.
 
-To keep this chapter focused on learning async-await, rather than juggling parts
-of the ecosystem, we have created the `trpl` crate. (`trpl` is short for “The
-Rust Programming Language”). It re-exports all the types, traits, and functions
-you will need, and in a couple cases wires up a few things for you which are
-less relevant to the subject of the book. There is no magic involved, though! If
-you want to understand what the crate does, we encourage you to check out [its
+To keep this chapter focused on learning async, rather than juggling parts of
+the ecosystem, we have created the `trpl` crate. (`trpl` is short for “The Rust
+Programming Language”). It re-exports all the types, traits, and functions you
+will need, and in a couple cases wires up a few things for you which are less
+relevant to the subject of the book. There is no magic involved, though! If you
+want to understand what the crate does, we encourage you to check out [its
 source code][crate-source]. You will be able to see what crate each re-export
 comes from, and we have left extensive comments explaining what the handful of
 helper functions we supply are doing.