'Function Coloring'

9 days ago

Copy Link

The blog post discusses the concept of 'function coloring', where functions are divided into async and normal functions, creating a divide that complicates programming.
The author relates this to their experience with Haskell, where adding I/O (like a print statement) changes a function's type and affects all calling functions, making the issue 'infectious'.
Over time, the author developed better testing methodologies and a clearer separation between I/O and program logic, reducing the 'coloring' problem in Haskell.
Despite improvements, Haskell still requires separate functions for monadic operations (e.g., `mapM`, `filterM`), highlighting ongoing challenges with effect management.
The post explores whether async functions (returning `Promise<T>`) face similar 'coloring' issues, noting composition problems like nesting types and the inability to call async from non-async contexts.
Escape hatches exist, such as blocking or using global state, but these are not ideal solutions.
The author argues that exposing asynchrony explicitly (via promises/async-await) aligns better with how the world works, compared to implicit synchronous models that hide asynchrony.
Green threads (like in Go) don't eliminate 'function coloring'; they just hide it, potentially leading to silent sequential execution instead of concurrency.
The post concludes that while async/await has drawbacks, making asynchrony explicit may be better than pretending everything is synchronous.

Hasty Briefsbeta