> [!note] [link](https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/) > An influential article that introduced the red-green functions as a framework for thinking about callback code: > 1. every function has a color > 2. the way you call a function depends on its color > 3. you can only call a red function from within another red function > 4. red functions are more painful to call > [!note] > Red - async, Green - sync functions This article ends with a praise for [[Go]], which is still relevant in 2025: > [!quote] > Go is the language that does this most beautifully in my opinion. As soon as you do any IO operation, it just parks that goroutine and resumes any other ones that aren’t blocked on IO. > > If you look at the IO operations in the standard library, they seem synchronous. In other words, they just do work and then return a result when they are done. But it’s not that they’re synchronous in the sense that it would mean in JavaScript. Other Go code can run while one of these operations is pending. ==It’s that Go has eliminated the distinction between synchronous and asynchronous code==. > [!thought] [[2025-06-05]] > Modern [[JavaScript]] made this less relevant. > - [[Future|Promises]] are much easier to use than callbacks, so there's less *syntactic overhead* of introducing and interoperating with async functions is not that difficult. > - it is still true that synchronous code cannot call async code. However, with promises, at least promises can be passed around. (`map` with async function works well, even though `map` is not async). > - In many cases non-async type signature can signify that it doesn't want any io / interrupt to happen. Related: [[Future|Async-Await]], [[Asynchronous Programming]]. # Current assessment ## [[JavaScript]] In front-end (React) this is less of a concern; The "red" functions being difficult to call is a feature; React's main event loop is designed to be synchronous; you cannot perform async operations on `useEffect`, or `useReducer`, for example. In back-end, this is still problematic, but less so; in your application code, it's relatively easy to migrate from synchronous to async code (just sprinkle some `async` and `await`s around).