November 1, 2025
Benchmarks or bust
A Few Words About Async
Async wars erupt: speed vs snappy, show us benchmarks, BEAM fans crash the party
TLDR: The post argues async is about quick responses, not raw speed, and warns heavy computing won’t benefit. Commenters clap back, demanding benchmarks, touting .NET upgrades, and flexing Elixir/Rust cred—turning a technical explainer into a language war over what “fast” really means.
The author drops a long, thoughtful take: async (the “do something else while you wait” style) isn’t about brute speed, it’s about latency—getting something back fast so apps feel responsive. Think: 16 milliseconds to react in a game, a second or two for a web server. The piece warns that wrapping heavy number crunching in async can be slower, and uses a hilariously inefficient Fibonacci example to make the point. There’s even a nod to classic UX science on response times from Nielsen Norman Group.
Then the comments set the room on fire. sema4hacker demands benchmarks and calls the post “all-hat-and-no-cattle,” which became the meme of the thread. neonsunset counters with optimism, saying .NET’s upcoming “Runtime Async” could blunt the performance hit. jiggunjer admits async confusion after a Python library quietly spun up threads, asking if “multiple async threads on one core” is even a thing—cue facepalms. travisgriggs rolls in with Elixir/Erlang swagger: the BEAM crowd insists their event loop culture avoids the “awkward entanglement” other languages get. Finally, vlovich123 fact-checks the claim about no async/await on Linux’s io_uring, pointing to Rust projects that do exactly that. The vibe: a spicy mix of language pride, performance nitpicking, and “show your numbers” energy. Bonus joke: “16ms or die” became the rallying cry.
Key Points
- •The article distinguishes throughput from latency and argues modern applications should prioritize responsiveness.
- •Most contemporary environments execute code within an event loop, including asyncio, Tokio, Eio, browsers, Node.js, and BEAM.
- •User-facing applications have tight response-time budgets (~16 ms), making certain operations infeasible within a single event iteration.
- •Typical web servers can tolerate about 1–2 seconds, but tasks like heavy database queries or generating LLM output may exceed that.
- •A naive, CPU-bound Fibonacci example shows how long-running computation can exceed latency budgets and block event-driven responsiveness.