The Function Colour Myth, Or: async/await is not what you think it is
lukasa.co.uk
lukasa.co.uk
> Bob’s rant about function colour is actually a rant about proactor vs reactor programming. His argument is that it is better to write code that blocks on I/O than code that expects its I/O to be done for it elsewhere in the code.
Yes, threading is hard. And he’s right that lots of async can be unnecessarily hard too.
However…
> But you don’t need to do [async]. 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.
Ok… not sure how he got there. I have a gateway program right now that is definitely not just 10% IO. It’s like 95% IO. It seems a weird generalization to assume my programs will be similar to his.
Agreed. When a program exists mostly to coordinate the activity of other programs, most code in that program will be doing IO of various sorts, not crunching data. It's easy for someone who's written primarily data-crunching code to underestimate just how IO-intensive some other programs are --- and vice versa.
Go doesn't have a problem with function color because they are all coroutines and can suspend on any library call.
Java doesn't have a problem calling or waiting on any function, but it does suffer from thread usage if done too much. This is due to a lack of coroutines.
JavaScript/Node somehow decided that the main thread isn't like all the other coroutines. This is the problem. Make them all coroutines as is done in Go, with the same caveat that if the main one exits the 'program' ends, so it should await anything it needs to.
async/await is just syntax that removes boilerplate from some common patterns like returning a future and yielding execution while waiting on its result. You could implement this yourself in every function, but people don't want to and find async/await convenient. So here we are.
Maybe it's just me, but the whole function color thing really comes off as "why can't I store a string in an int variable? The compiler could call itoa for me why doesn't it?". I mean if that's what you want go use a language where the compiler does that for you. We're here using types because we care about code correctness and are willing to endure some compile time restrictions to achieve it.
If you're going to argue with someone you really need to know the material