> "colorless" (which is always a lie) No, colourless isn't a lie. Erlang doesn't have two types of function (sync and async). C#/Python now do. As a functio

> "colorless" (which is always a lie) No, colourless isn't a lie. Erlang doesn't have two types of function (sync and async). C#/Python now do. As a function/method implementer in those languages, for every single function implementation, I am faced with the following: 1. My function has to be async, because someone, somewhere, in the call chain of functions I want to invoke, decided to make their function async. So I have to deal with the downsides (lower performance, debugging complexity) whether I need the upsides or not. 2. I need to decide whether to make my function async because the decision hasn't been taken out my hands somewhere down the call stack. If I'm writing a library function that means I'm now having to judge how callers will use my function. If I decide async, then I've imposed constraints on the caller as per #1. 3. I need to implement sync & async versions of my function so as not to constrain the choices of my callers. That emerges because of (1) the asymmetric constraint imposed by async/await and (2) the requirement for function implementers to make the decision, not callers. A sync function can't call an async one. That's the basis of colouring. It's not a lie. > the article about function coloring is actively harmful to the industry No, the article about colouring very clearly explains the asymmetric nature of sync/async and the limitation it imposes. Its use of colour as a metaphor very clearly illustrates the issue. Sure, there's a risk that some people won't fully read and understand it - and then just parrot "yeah, coloured is bad". That's not the fault of the article though. There's nothing inherently wrong with Futures as a concurrency construct: it's essentially enabling cooperative multitasking. The issue is that async/await as an implementation causes codebase bifurcation. > all BEAM-based languages are comparatively slow Emphasis on "comparative". I don't disagree that in certain dimensions - notably raw compute performance and memory usage - BEAM languages are comfortably down the benchmark tables compared to C#. That doesn't always translate to real world practicality though (and even throughput is getting better given the active JIT work). > developers are insistent on parroting quotes said 10 to 15 years ago instead of at least attempting to assess technologies on their merits of today. Futures have merit per above. Async/await brings syntactic convenience which, in isolation, is an improvement. But with it comes significant cost. Cost that isn't there with green threads and isn't intrinsic to Futures either. You can't just sweep those limitations under the carpet by promulgating the hubris that the arguments are old.