
The Function Colour Myth (or async/await is not what you think it is) - ngrilly
https://lukasa.co.uk/2016/07/The_Function_Colour_Myth/
======
paulddraper
> 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.

~~~
zzzcpan
> suddenly you have all the benefits of async

You don't have the most important one - synchronization-free concurrency, that
you can get only by explicitly giving up control.

~~~
paulddraper
Synchronization-free concurrency -- or concurrency without parallelism -- is a
separate issue. E.g. Async JS has it, but async Java does not.

(Also, I must point out that single-threaded concurrency instead of true
parallelism ignores most of the available performance of modern hardware.)

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

