







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.
397 - Challenges with async/await in the control plane | RFD | Oxide
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: 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 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.
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.
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.
ABSD
An experimental operating system in Rust: isolated processes, explicit authority, and claims stated at the strength of their evidence. Source is public.

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.
The Definitive Guide to Error Handling in Rust
Learn to model and handle any error using idomatic Rust.

Making Rust Workers reliable: panic and abort recovery in wasm‑bindgen
Panics in Rust Workers were historically fatal, poisoning the entire instance. By collaborating upstream on the wasm‑bindgen project, Rust Workers now support resilient critical error recovery, including panic unwinding using WebAssembly Exception Handling.

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…

Why Use Structured Errors in Rust Applications?
Going against the common wisdom of “using anyhow for applications”.
Announcing Rust 1.96.1 | Rust Blog
Empowering everyone to build reliable and efficient software.

One year of Rust | Rust Blog
Empowering everyone to build reliable and efficient software.

Rust Error Handling: thiserror, anyhow, and When to Use Each
In this blog post, we’ll explore strategies for streamlining error handling in Rust using two popular libraries: thiserror and anyhow. We’ll discuss their features, use cases, and provide insights on when to choose each library. TL;DR thiserror simplifies the implementation of custom error type, removing boilerplates anyhow consolidates errors that implement std::error::Error While thiserror provides detailed error information for specific reactions, anyhow hides internal details Return Different Error Types from Function Let’s start by creating a function decode() for illustration. The function has 3 steps: