In some runtimes, calling an asynchronous function forces the caller to be asynchronous too, splitting an API into two parallel worlds. What causes that split, what problems does it create, and which designs avoid it?

## Where the split comes from A stackless coroutine is a compile-time rewrite: the function body becomes a state machine with a heap frame holding its resume point and live locals. Only functions that were rewritten have such a frame. Now consider an ordinary function calling a suspendable one and wanting its result. When the callee suspends, control must return all the way to the scheduler — but the ordinary caller's frame lives on the real stack and would be destroyed. So the caller must also be rewritten. Inductively, the property spreads to the whole call chain up to a scheduler entry point. That is the mechanism. The two "colors" are not a syntax preference; they mark which functions the compiler transformed. ## The costs **API duplication.** Any library offering both worlds carries two surfaces, often with near-identical logic. They drift. **Adoption is a breaking change.** A widely used library cannot make an operation suspendable without recoloring every caller. In practice ecosystems fork into sync and async halves, and each half re-implements HTTP clients, drivers, test harnesses, and instrumentation. **Higher-order abstractions multiply.** A generic collection operation, a retry combinator, a comparator, a resource-scope helper: each needs a suspendable variant, because a callback that can suspend forces its caller to. Generic code that should be color-polymorphic cannot be. **Interfaces are colored.** Once a method on an interface is suspendable, every implementation is — including trivial in-memory or test ones that never wait. Conversely, an interface designed synchronously cannot host a suspendable implementation without redefinition. **Bad escape hatches.** Two appear under deadline pressure: - *Sync over async*: block a thread waiting for an async result. On a bounded pool this can deadlock — the thread you are blocking is one the completion needs to run on — and at minimum it reintroduces the thread-per-wait cost you were avoiding. - *Async over sync*: wrap a blocking call in a task submitted to a pool so it looks suspendable. Nothing became non-blocking; you moved the blocked thread and hid the capacity cost behind an interface that promises cheapness. **Diagnostics and cross-cutting concerns.** Context propagation, tracing, timeouts, and error handling frequently need two implementations, one per color. ## Designs that remove the split **Stackful coroutines / user-mode threads.** Give each task a real stack that the runtime can park and resume. Any frame at any depth can suspend, so an ordinary-looking call can wait without holding an OS thread. Existing blocking-style code becomes scalable without recoloring. Costs: stack memory per task, pointer-stability and pinning problems when foreign frames are on the stack, and it needs runtime/platform support. Also, blocking calls that bypass the runtime (native calls, some file APIs, certain lock primitives) still pin a carrier thread, so the transparency is not absolute. **Effect systems / capability polymorphism.** Type "may suspend" as an effect and allow functions to be generic over it, so one `map` serves suspending and non-suspending callbacks. This keeps the information visible and static without duplicating APIs. The cost is a heavier type system and steeper learning curve; it is mainstream in a few languages and research-grade elsewhere. **Uniform async.** Make everything suspendable; no second color exists. Simple, but you pay transform overhead everywhere and lose the syntactic signal. ## The argument for keeping colors Colors are documentation. A visible suspension marker tells the reader: another task may run here; an invariant must hold here; cancellation can land here; a value read before this point may be stale after it. In colorless models, any call might yield, so reviewers cannot enumerate interleaving points by reading — they are back to preemptive-style reasoning, just without kernel preemption. Colors also make the cost of I/O visible in the type, which some teams value. ## How to answer as a decision Frame it as a portfolio call. For a **greenfield high-density service** in an ecosystem whose libraries are already suspendable, colors cost little and buy auditability. For a **large existing codebase** with deep blocking dependencies you do not control, a colorless model is worth its stack cost because it eliminates a rewrite you would otherwise never finish. For a **library author** in a colored ecosystem, the crucial rule is never to fake either direction: expose the color your implementation actually is, and let the caller choose the bridge with full knowledge of the thread cost.