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 system due to how the language is designed and its core values.

However, much of the perceived complexity today has more to do with the ecosystem and the kind of issues that result from a lot of programmers having to agree on the best way to solve different problems without any formal structure. The ecosystem gets fragmented for a while, and together with the fact that asynchronous programming is a topic that’s difficult for a lot of programmers, it ends up adding to the cognitive load associated with asynchronous Rust.

All the issues and pain points I’ve mentioned in this chapter are constantly getting better. Some points that would have been on this list a few years ago are not even worth mentioning today.

More and more common traits and abstractions will end up in the standard library, making async Rust more ergonomic since everything that uses them will “just work.”

As different experiments and designs gain more traction than others, they become the de facto standard, and even though you will still have a lot of choices when programming asynchronous Rust, there will be certain paths to choose that cause a minimal amount of friction for those that want something that “just works.”

With enough knowledge about asynchronous Rust and asynchronous programming in general, the issues I’ve mentioned here are, after all, relatively minor, and since you know more about asynchronous Rust than most programmers, I have a hard time imagining that any of these issues will cause you a lot of trouble.

That doesn’t mean it’s not something worth knowing about since chances are your fellow programmers will struggle with some of these issues at some point.