Why a Single await Can Turn Half Your Project Red

Developers often encounter a frustrating scenario: converting a regular function such as fetch_user() into an asynchronous one with await fetch_user() forces the caller to become async def, and this change ripples up the call chain to routers, entry points, and tests, turning half a project "red".

The roots of async programming go back to 1976, when Indiana University researchers Daniel Friedman and David Wise introduced the term promise in their paper "The Impact of Applicative Programming on Multiprocessing". In 1977, MIT’s Henry Baker and Carl Hewitt presented the concept of future in "The Incremental Garbage Collection of Processes". These ideas later became core keywords in JavaScript, Python, and Rust, though the original papers had nothing to do with web servers.

After the 1999 "C10K Problem" highlighted the limits of one‑thread‑per‑connection architectures, the industry moved to event loops, non‑blocking I/O, and callbacks (e.g., nginx, Node.js). Callback hell led to the desire for code that looks synchronous. C# 5.0 introduced async / await in 2012, followed by Python 3.5 (2015), JavaScript ES2017, Rust 1.39 (2019), and Swift 5.5 (2021). The feature made linear I/O code readable and easier to debug.

Bob Nystrom’s 2015 essay "What Color is Your Function?" coined the metaphor of function coloring . A red function (async) must be called by red code, can call blue (sync) functions, but blue functions cannot call red ones, and red functions are harder to write. This "async coloring" spreads up the call chain, creating the "function‑coloring problem".

Another hidden pitfall is the illusion of sequential dependencies. Code such as:

const user = await getUser(id);
const orders = await getOrders(user.id);
const recommendations = await getRecommendations(user.id);

looks clean but often the orders and recommendations calls are independent and could run in parallel. Sequential awaits can turn potentially concurrent operations into a performance bottleneck, especially in large services.

The async ecosystem also introduced runtime fragmentation. Rust provides Future and async/await but no built‑in runtime, leading to incompatible runtimes like Tokio, async‑std, and smol. This adds another layer of "color" to functions, as futures from one runtime cannot be used directly in another.

Some languages are choosing different paths. Java’s Project Loom (JDK 21, 2023) offers virtual threads, allowing synchronous‑style code without async/await, thus avoiding function coloring. Zig has even removed the async and await keywords entirely, opting for an I/O abstraction passed as a parameter, letting the runtime decide between blocking I/O, thread pools, or event loops.

In summary, async/await solved callback hell and improved readability, but it introduced a new form of technical debt—function coloring, hidden sequential dependencies, and ecosystem incompatibilities. Developers should weigh whether a function truly needs to be async, examine real dependencies, and consider alternatives like virtual threads or I/O abstractions to avoid the hidden costs.