https://www.snoyman.com/blog/2018/12/rust-crash-course-07-async-futures-tokio

I also blog frequently on the Yesod Web Framework blog, as well as the FP Complete blog.

See a typo? Have a suggestion? Edit this page on Github

Unlike languages like Haskell, Erlang, and Go, Rust does not have a runtime system providing green threads and asynchronous I/O. However, for many real world use cases, async I/O is strongly desired, if not a hard requirement. The de facto standard library for handling this in Rust is tokio.

This post is part of a series based on teaching Rust at FP Complete. If you’re reading this post outside of the blog, you can find links to all posts in the series at the top of the introduction post. You can also subscribe to the RSS feed.

This lesson in the crash course is going to be a bit different from others, since:

  1. There’s a lot of interconnected material to cover which can’t as easily be separated out
  2. It’s more important to understand the motivation behind the design of these libraries than in many other cases
  3. I believe the material may be useful for people who haven’t been following the rest of the crash course

Therefore, some different rules will apply:

Also, this lesson is much longer and more involved than previous lessons. You should plan on it taking more time to complete than others. I considered breaking this up into multiple lessons, but decided to keep all of the content together. Instead, I’ll be taking a break from weekly lessons after this one for a bit.

Consider that the intro to the intro. Now the real intro!

Why async?

I’m going to assume that readers are already familiar with async I/O and its motivations in general. If you’re not, it’s worth reading up a bit on the C10k problem, where many of us started thinking hard about async I/O. You may also be interested in reading a post I wrote about green threads, a language runtime-based solution to the same problem.

At the end of the day, the goals of Rust’s approach to async I/O are: