So, in this chapter, we did two things. First, we made some rather minor changes to our runtime so it works as an actual runtime for Rust futures. We tested

Some of the things that make async Rust different from other languages are unavoidable. Asynchronous Rust is very efficient, has low latency, and is backed by a very strong type

The last topic that causes friction in async Rust is the lack of universally agreed-upon traits and interfaces for typical async operations. I want to preface this segment by pointing

Rust is good at being ergonomic and efficient, and that almost makes it difficult to remember that when Rust is faced with the choice between being efficient or ergonomic, it

So, while we’ve seen with our own eyes that the executor and reactor could be loosely coupled, which in turn means that you could in theory mix and match reactors

Calling Runtime::new creates a multithreaded Tokio runtime, but Tokio also has a single-threaded runtime that you can create by using the runtime builder like this: Builder::new_current_thread().enable_all().build().unwrap(). If you do that,

Note You’ll find this example in the book’s repository in the ch10/b-rust-futures-experiments folder. The different experiments will be implemented as different versions of the async_main function numbered chronologically. I’ll indicate

The first thing we do is to make sure our dependencies are correct. We have to remove the dependency on our old Waker implementation and instead pull in these types

This is an example of Rust adopting what turns out to be best practices from the ecosystem. For a long time, a popular way to construct wakers was by implementing

The first thing we need to change in executor.rs is our dependencies. This time, we only rely on types from the standard library, and our dependencies section should now look