The Function Colour Myth (or async/await is not what you think it is)

> I’m serious: every time you write async in your code you have made a small admission of defeat. You couldn’t come up with a clear way to construct your code that didn’t involve you needing to do some form of I/O in the middle of it.

> But you don’t need to do it. With care, there is no reason for more than about 10% of your codebase to be async functions. Almost all the rest of your code can just transform in-memory data representations from one form to another.

Wouldn't the world be great if we didn't need I/O?

But in the real world, I/O is need very often: disk reads, HTTP requests, database queries, etc. Even more important, I can't predict where and when I'll need I/O.

For example, my JS frontend has function that converts a LaTeX to an SVG. A perfect example "transform in-memory data representations from one form to another". Except...we noticed that MathJax and all its fonts can really take a toll on bandwidth, so now we want to change the conversion implementation to lazily load these over HTTP. Oops, now my "in-memory transform" suddenly acquired I/O. It sure would be a lot simpler if all information were on one machine all the time. :/

---

FYI, async is only a thing because implementation details make OS threads heavy. Reduce the stack size to nearly nothing and change the schedulers to not flush memory caches on context switches, and suddenly you have all the benefits of async. (Granted, this won't happen soon, and so we create application-level "threads" (sequenced code), rather than use OS ones.)

So, I agree there is some arbitrariness at play here. Pushed to the extremes, sync == async.

I mostly agree, functions are way too powerful abstractions to introduce sugar on top of them.