Why Async/Await Might Be Overcomplicating Programming

I’ve been reflecting on a meme I saw about async and await—it perfectly captures my frustration with these concepts. Once you start using async functions, it seems like every function that depends on them has to be async as well. This cascades up to the top level, creating a chain reaction of asynchronous code.

My recent experience with Go has made me reconsider the necessity of async/await. Go, despite its strong support for concurrency, doesn’t use async/await. Instead, it handles delays with simple constructs like time.Sleep(1 * time.Second). This straightforward approach contrasts with the convoluted syntax required for await.

In Go, I was surprised to see that threading isn’t needed for simple delays. You’d expect something complex, but no—Go manages it efficiently without await. This simplicity is refreshing.

I’ve always found async functions overcomplicated. They can make code harder to read and understand, especially when trying to deal with asynchronous operations like network requests. In languages like Dart, where I use lints like unawaited_futures, I see the need to explicitly handle async operations to avoid confusion.

Performance concerns with async functions can be real, but often they stem from the nature of the operation—like network requests—not the async keyword itself. Alternative approaches, like Go’s go foo(), offer asynchronous capabilities without requiring async functions, thus keeping things simpler.

The core issue with async/await is that it enforces an asynchronous model on all functions, regardless of whether it’s needed. This can lead to unnecessary complexity and potential performance pitfalls. In fact, Dart has even introduced lints suggesting that certain synchronous IO operations should remain synchronous to avoid performance overhead.

Ultimately, while asynchronous programming is valuable, the async/await model might complicate things more than it needs to. Sometimes, a simpler approach—like Go’s model—can be more effective, avoiding the pitfalls of forcing all functions to be asynchronous.