Very early in the development of the control plane, we considered whether to build our big new distributed system using Rust’s async/await or more traditional synchronous threaded code. [RFD 79] discussed this issue and came to the weak conclusion to prefer async/await, in no small part because much of the ecosystem we wanted to use (e.g., low-level http crates) was already async and seemed to be moving further in that direction, and we’d already written some async code.
Async from scratch 1: What's in a Future, anyway? | natkr's ramblings
There are a lot of guides about how to use async Rust from a "user's perspective", but I think it's also worth understanding how it works, what those async blocks actually mean. Why you get all those weird pinning errors.
Async: What is blocking? – Alice Ryhl
The async/await feature in Rust is implemented using a mechanism known as cooperative scheduling, and this has some important consequences for people who write asynchronous Rust code.
async/await: It’s Good and Bad
This might be controversial, as most people I know are huge fans of async/await. If you’re not familiar, it’s this nifty little syntax…
400 - Dealing with cancel safety in async Rust | RFD | Oxide
While developing the control plane, we’ve found that one of the bigger practical issues has been async cancel correctness: the relatively unpredictable way an async Rust system can behave if futures are dropped [rfd397]. Cancellation is an example of "spooky action at a distance", and having to think about it imposes a significant cognitive burden on authors and reviewers of asynchronous code. Both of these are quite uncharacteristic of Rust.
Building a mental model for async programs
In my experience writing async programs in Dart and Rust, I have built up a model in my head to avoid bugs caused by async. These bugs are usually hard to find and reproduce, so there is a lot of value in taking preventive measures to avoid them. I hope to improve this model in my head by writing this post and to share them with anyone who might find it helpful.
Exploring ways to make async Rust easier
Asynchronous Rust is powerful but has a reputation for being hard to learn. There have been various ideas on how to fix the trickiest aspects, though with my focus being on Tokio 1.0, I had not been able to dedicate much focus to those topics. However, Niko’s async vision effort has recently started the discussion again, so I thought I would take some time to participate. In this article, I collect some previously proposed ideas and offer some new ones, tying them together to explore what could be.
Async/await on the GPU
GPU code can now use Rust's async/await. We share the reasons why and what this unlocks for GPU programming.
Async/await on the GPU
GPU code can now use Rust's async/await. We share the reasons why and what this unlocks for GPU programming.
Composing Time: Compositional Async in Solid 2.0
RustFest Interviews Triple Feature: Rust for AAA Game Development; Async Foundations with `async-std`; and Powerful Concurrency Primitives with `crossbeam` :: Rustacean Station
Come journey with us into the weird, wonderful, and wily world of Rust.
Announcing Topcoat: a framework for building full-stack reactive web apps with Rust | Tokio - An asynchronous Rust runtime
Tokio is a runtime for writing reliable asynchronous applications with Rust. It provides async I/O, networking, scheduling, timers, and more.
A Design Space Exploration of Async/Await
Many modern programming languages include some form of asynchronous programming. In particular, a growing number now have what we call straight-line asynchrony: attempts to provide asynchronous functions that look similar to synchronous functions, thereby enabling asynchrony without introducing complex control. These languages often share construct names like "async" and "await," which suggests that they have deep semantic similarities. Yet, a close examination reveals that these languages are quite different along several dimensions, often subtly. These differences have real semantic consequences: similar-looking programs can exhibit divergent behavior, confusing developers and language designers alike. This paper therefore presents a design space exploration of straight-line asynchrony. We dissect several existing languages, and show how no two of them agree as a whole on design decisions that affect the presence and ordering of execution. We articulate a design space with nine dimensions covering the full lifecycle of an asynchronous computation, covering questions such as: What precise guarantees does a language give upon calling an asynchronous function? What happens at the end of a task's life? How can a task handle being cancelled? We explore these questions through concrete examples, informal design discussion, and a formal semantics. Our ultimate goal is to help programmers, language designers, and language theorists all better understand the emerging landscape of straight-line asynchrony.
rumqttc - Rust
A pure rust MQTT client which strives to be robust, efficient and easy to use. This library is backed by an async (tokio) eventloop which handles all the robustness and and efficiency parts of MQTT but naturally fits into both sync and async worlds as we’ll see