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 the runtime using two external HTTP client libraries to learn a thing or two about reactors, runtimes, and async libraries in Rust.

The next thing we did was to discuss some of the things that make asynchronous Rust difficult for many programmers coming from other languages. In the end, we also talked about what to expect going forward.

Depending on how you’ve followed along and how much you’ve experimented with the examples we created along the way, it’s up to you what project to take on yourself if you want to learn more.

There is an important aspect of learning that only happens when you experiment on your own. Pick everything apart, see what breaks, and how to fix it. Improve the simple runtime we created to learn new stuff.

There are enough interesting projects to pick from, but here are some suggestions:

• Change out the parker implementation where we used thread::park with a proper parker. You can choose one from a library or create a parker yourself (I added a small bonus at the end of the ch10 folder called parker-bonus where you get a simple parker implementation).
• Implement a simple delayserver using the runtime you’ve created yourself. To do this, you have to be able to write some raw HTTP responses and create a simple server. If you went through the free introductory book called The Rust Programming Language, you created a simple server in one of the last chapters (https://doc.rust-lang.org/book/ch20-02-multithreaded.html), which gives you the basics you need. You also need to create a timer as we discussed above or use an existing crate for async timers.
• You can create a “proper” multithreaded runtime and explore the possibilities that come with having a global task queue, or as an alternative, implement a work-stealing scheduler that can steal tasks from other executors’ local queues when they’re done with their own.

Only your imagination sets the limits on what you can do. The important thing to note is that there is a certain joy in doing something just because you can and just for fun, and I hope that you get some of the same enjoyment from this as I do.

I’ll end this chapter with a few words on how to make your life as an asynchronous programmer as easy as possible.

The first thing is to realize that an async runtime is not just another library that you use. It’s extremely invasive and impacts almost everything in your program. It’s a layer that rewrites, schedules tasks, and reorders the program flow from what you’re used to.

My clear recommendation if you’re not specifically into learning about runtimes, or have very specific needs, is to pick one runtime and stick to it for a while. Learn everything about it – not necessarily everything from the start, but as you need more and more functionality from it, you will learn everything eventually. This is almost like getting comfortable with everything in Rust’s standard library.

What runtime you start with depends a bit on what crates you’re using the most. Smol and async-std share a lot of implementation details and will behave similarly. Their big selling point is that their API strives to stay as close as possible to the standard library. Combined with the fact that the reactors are instantiated implicitly, this can result in a slightly more intuitive experience and a more gentle learning curve. Both are production-quality runtimes and see a lot of use. Smol was originally created with the goal of having a code base that’s easy for programmers to understand and learn from, which I think is true today as well.

With that said, the most popular alternative for users looking for a general-purpose runtime at the time of writing is Tokio (https://tokio.rs/). Tokio is one of the oldest async runtimes in Rust. It is actively developed and has a welcoming and active community. The documentation is excellent. Being one of the most popular runtimes also means there is a good chance that you’ll find a library that does exactly what you need with support for Tokio out of the box. Personally, I tend to reach for Tokio for the reasons mentioned, but you can’t really go wrong with either of these runtimes unless you have very specific requirements.

Finally, let’s not forget to mention the futures-rs crate (https://github.com/rust-lang/futures-rs). I mentioned this crate earlier, but it’s really useful to know about as it contains several traits, abstractions, and executors (https://docs.rs/futures/latest/futures/executor/index.html) for async Rust. It serves the purpose of an async toolbox that comes in handy in many situations.