Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] async and .await chapter #3909

Closed
wants to merge 214 commits into from
Closed

[WIP] async and .await chapter #3909

wants to merge 214 commits into from

Conversation

carols10cents
Copy link
Member

@carols10cents carols10cents commented Apr 30, 2024

A working draft of a new chapter on async and await! If you have been invited to give comments, please do so! (If you’re not someone we have actively invited, we kindly ask you to hold off: although we are working in public, we cannot absorb too much feedback at once. Thanks!)

View the rendered version of this PR at https://rust-lang.github.io/book/ch17-00-async-await.html.

Note

This branch does not include changes to the listings for the chapters after this new chapter. As @carols10cents put it:

😬 GitHub is straight up not having a good time rendering the full diff of #3908 with all the listing changes 😱

Additionally, we will need to make some other small changes to other chapters (and possibly some significant ones to the “final project” chapter) to account for having this new material in place. Those are all also out of scope for this PR!

We will primarily just be re-exporting this, though we may also have a
couple cases where we choose to implement something small around it.
1. Introduce an integration tests crate. Structure it the way people
   *should* for large crates (although this is not that) and document
   why, including linking to a relevant post.
2. Add a basic integration test that verifies the re-export works as it
   should. (This is not exactly rocket science, but we want to make sure
   these things don’t just stop working on accident.)

An open question that remains here: do we want some structure to the
crate beyond the top level re-exports? My inclination at this moment is:
no, because we don’t have any *motivation* for that, and naming things
is difficult. (We cannot do `trpl::async`, for example, because `async`
is a keyword!)
- 17.00: Introduction to the conceptual machinery. This is very nascent
  but has some decent bones.
- 17.01: Trying to get at the foundations for tasks, laziness, etc.;
  this is *especially* incomplete.
- 17.02: Just a paragraph I do not want to lose, which I think *will*
  be useful… eventually.
Add a fair bit more material about the `futures` executor and why we
might prefer to use something else. With that motivation in place, have
the readers add our `trpl` crate. (We can of course rename that crate,
but it does the job for now.) Use it to get the equivalent of
`#[tokio::main]` equivalent and incorporate it into an example.
Copy link
Member Author

@carols10cents carols10cents left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some context on these comments: I know this is an early draft, but I have pointed out some things that appear small but I think are important for us to figure out while working, like figuring out what terminology we should standardize on and where we should define which terms. Please feel free to tell me "yeah yeah I agree but don't want to think about that right now" :)

src/ch17-00-async-await.md Outdated Show resolved Hide resolved
src/ch17-00-async-await.md Outdated Show resolved Hide resolved
src/ch17-00-async-await.md Outdated Show resolved Hide resolved
src/ch17-00-async-await.md Outdated Show resolved Hide resolved
src/ch17-00-async-await.md Outdated Show resolved Hide resolved
src/ch17-01-tasks.md Outdated Show resolved Hide resolved
src/ch17-01-tasks.md Outdated Show resolved Hide resolved
src/ch17-01-tasks.md Outdated Show resolved Hide resolved
src/ch17-01-tasks.md Outdated Show resolved Hide resolved
src/ch17-01-tasks.md Outdated Show resolved Hide resolved
@chriskrycho
Copy link
Contributor

things that appear small but I think are important for us to figure out while working, like figuring out what terminology we should standardize on and where we should define which terms.

1,000% on board with this!

Also very on board with working on this separate branch. I will likely keep the other around for reference (and we may even be able to merge it when all is said and done, who knows), but it will be a lot easier to deal with the mechanical bits separately from the prose bits, and we really don’t want to land any of that till we are actually ready to land the chapter. 😅

I have replied to most of the comments here, and I have read all of them; if I haven’t yet replied to one it is just because I am still mulling on it!

@chriskrycho chriskrycho force-pushed the only-new-async branch 2 times, most recently from f3fc42f to 87a015f Compare May 10, 2024 14:46
chriskrycho and others added 17 commits August 24, 2024 08:19
- Set their view boxes to the original height and width, so they are
  guaranteed to present correctly.
- For Figure 17-02, use the trick of adding a hidden node and hidden
  arrow to it in “Task 2” to align the two boxes.
- Create a section (which will be deleted or at least reintegrated once
  all is said and done) to hold content pulled out of other sections for
  the sake of clearer flow and understanding.
- Pull “advanced” material from 17.00, 17.01, and 17.02 into the holding
  section and start reorganizing their content to account for shifting
  around materials.
The `block_on` name is what both Tokio and smol use, but it is a bit
obscure from the point of view of introducing this material. `run` says
much more clearly what it does *for the level we care about here*, I
think.
These make up *most* of the rest of the edits I caught while rereading
which are not *major structural revisions*, along with some of the bits
required for those major structural revisions.
This does *not* yet incorporate any of the relevant feedback from Carol
on this, so a couple spots are still pretty messy.
Along with the wording and phrasing-level edits, pull out a fair bit of
material for the “advanced” section at the end, specifically the details
of what `Stream` and `StreamExt` actually do.
Bonus: fix some style guide issues, too!

Co-authored-by: Carol (Nichols || Goulding) <[email protected]>
Co-authored-by: James Munns <[email protected]>
Co-authored-by: Tim McNamara <[email protected]>
Co-authored-by: Tim McNamara <[email protected]>
Co-authored-by: Carol (Nichols || Goulding) <[email protected]>
@chriskrycho chriskrycho mentioned this pull request Sep 13, 2024
3 tasks
I accidentally copied these in when pulling in the `trpl-note` mdbook
preprocessor many months ago, and we did not notice amidst the many
other changes in that PR!
Add `reqwest` and `scraper` dependencies to the `trpl` crate. Wrap them
in `trpl` re-exports which keep the API surface low.

Rewrite the whole first section to use `race` along with those `trpl`
re-exports to show a more “real” example of async code right form the
start, including actual concurrency, unlike the previous introduction.

Update 17.03 to account for having introduced `race` already, and update
listing numbers for rewritten 17.01.

The *inclues* for them were fixed already, but not these!
This gets CI working again. The problem was basically a mix of a few
silly mistakes:

- Using `include` instead of `rustdoc_include` in several places.
- Having rewritten the listing numbers incorrectly.
@chriskrycho
Copy link
Contributor

All right, status: I have made a huge revision to the chapter—most of the content is the same, but the structure is very different, and I completely replaced the example in 17.01 to get “real” async happening up front much sooner. Given that this PR is basically destroying GitHub, I am going to:

  1. Merge More edits to the async chapter #4033 into it. There are some more things to do before this is 100% wrapped, but they are small, iterative improvements, rather than the major reworking that PR represents.
  2. Close this PR and open a new one. GitHub cannot handle this many comments (it can barely handle this many commits!), with a new branch.
  3. Publish the updated version of the trpl crate.
  4. Deploy the updated chapter to GitHub Pages for easy preview/review.

🚀

Just want to say here publicly (as I will do in many other places) a huge thanks to @timClicks, @willcrichton, and @jamesmunns as outside reviewers, and of course @carols10cents as co-author, whose input has made this a profoundly better chapter.

@chriskrycho chriskrycho mentioned this pull request Sep 23, 2024
3 tasks
@chriskrycho chriskrycho deleted the only-new-async branch September 23, 2024 16:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants