The author doesn't deconstruct the idea of function color at all: he just claims it's a good thing because threads are hard. The whole reason people talk about function color in the first place is that it turns out there's no such thing as a free lunch and there's a good reason threads work the way they do.
The problem isn't 'function' color, it's thread vs coroutines.<p>Go doesn't have a problem with function color because they are all coroutines and can suspend on any library call.<p>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.<p>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.
Isn't every function in the world (in non duck-type runtime languages) colored by its return type? Functions have signatures. You can't call a function that returns an int and store the value into a variable of type string. Similarly, you can't store a future<int> to a variable of type int without yielding execution and (a)waiting for the result to show up in some memory location and then copying that.<p>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.<p>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 I understand this argument, colored functions are not a requirement for concurrency, but they are convenient. But I didn’t follow why they are convenient. Is it because they are explicit? What convenience would you loose without colored functions?
Node isn't even async first, this doesn't come from c#, etc<p>If you're going to argue with someone you really need to know the material