You’ve been there. You’re writing a simple, elegant function. Everything is synchronous and clean. Then, you need to add a database call or a network request. Boom. Your function is now async. And the function calling it? async. The one above that? async. Within minutes, your entire call graph is infected with a color you never asked for.
We’ve all cursed the “what color is your function” problem. It’s the ultimate developer frustration. But what if we’ve been fighting the wrong enemy? What if the real issue isn’t the existence of colors, but our fundamental misunderstanding of what they actually are?
Function colors aren’t a law of nature—they’re a failure of your language’s imagination.
Here’s the twist: function colors are not function arguments. You probably treat them similarly because both feel like “extra inputs” you have to pass around. But arguments are supposed to be local and explicit. You pass a user ID to a function, it uses it, and it’s done. Colors, on the other hand, are implicit and transitive. They don’t just pass through one function; they infect every single layer of the stack.
Think about JavaScript’s async/await. It’s the classic example of function coloring. But it’s not a magical curse—it’s just an effect system. The problem is that in older implementations, the language gives you no way to abstract over that execution context. You can’t just pass the “async-ness” locally. It bleeds everywhere.
So, what happens when you try to treat these colors like arguments? This is where capability-style systems come in. You try to pass the context around explicitly. But here’s the hard truth: treating colors as arguments doesn’t fix your architecture; it just gives callback hell a fresh coat of paint.
If your type system can’t cleanly track and compose those contextual constraints, you haven’t solved the problem. You’ve just renamed it. You’re still manually threading state and execution context through every function signature, praying you don’t miss a layer.
Take Rust’s async functions. Under a strict framework, they aren’t “colored” in the traditional sense, because any function in the call stack can block on an executor. It’s a different mental model. The distinction matters because it reveals whether the boilerplate pain you feel is an inevitable cost of doing business, or a deliberate design choice by the language creators.
If adding one async call forces you to rewrite your entire stack, the language isn’t protecting you—it’s holding you hostage.
Stop blaming yourself for the friction. The next time you find yourself drowning in boilerplate, fighting a language’s structural constraints just to make a network call, recognize it for what it is. It’s not your fault. It’s a design choice that failed to abstract execution contexts properly.
Function colors aren’t arguments. They are contextual constraints that propagate through your call graph. Once you see the difference, the frustration of async propagation finally clicks into a coherent mental model. And more importantly, you know exactly what to demand from the next language you learn.
FAQ
Q: But doesn't async/await prevent blocking the main thread?
A: Yes, but that's the runtime's job. The language forcing you to manually propagate async through every function signature is a failure of abstraction, not a necessary safety feature.
Q: What's the practical takeaway for my daily coding?
A: Stop trying to fight the color by treating it like an argument. If your language forces transitive colors, lean into it or switch to a language with a real effect system that can track context without forcing you to rewrite your call graph.
Q: Is Rust's async model actually better then?
A: It's different. It abstracts the executor, but you still deal with futures. The real win is when a language's type system can track effects cleanly without forcing you to manually thread them through every layer.