> why doesn't C have colouring issues if it too supports asynchronicity But it does have those issues. In fact it is worse than in most other languages - just

> why doesn't C have colouring issues if it too supports asynchronicity But it does have those issues. In fact it is worse than in most other languages - just because there is no distinct support of async in a language does not mean it doesn't have async capabilities. C does have those, you just don't have any language support whatsoever, you have to take care yourself. Delegating the execution to the OS doesn't change that. For example, if you want to transform elements in an array concurrently, you now have to use pthreads. You cannot do that while using the same code as before (which is would removing function coloring is all about). Maybe we have a misunderstanding here: I'm talking abouyt sync/async not the async/await syntax that many languages have. The latter is to help deal with colored functions and the former is what enables the existance of concurrency. Any language that is - in one way or the other - capable of running code concurrently is suffering from that problem. It can be avoided by enforcing synchronous execution only, which some languages do (especially some DSLs), but most general purpose languages support concurrency. And once they do, there's two choices: the programmer has to deal with it (using Thread.async, spawn, pthreads, go channels, promises, ...) or they don't. If they don't then sync and async code must look exactly the same (or be able to be converted forth and back automatically). And this goal (either making it look the same or converting it automatically) is just not solvable in general. It has been tried for decades. For instance, check the paper "A Critique of the Remote Procedure Call Paradigm" from 1988. I think it was from Tanenbaum. It lists some of the problems that just cannot be solved in general. Some programs will always behave different after the automatic conversion, it's impossible to prevent that. > > Okay, let me follow up on this one. So could we take arbitrary Erlang/Elixir programs and automatically/mechanically rewrite them to push previously inlined calculations to be run on a different process (using spawn) or the otherway around - and that without causing any observable difference in behaviour in any situation except for difference in performance? > Yes. What I'm trying to explain is that you are mistaken. It just is not possible. Maybe in specific cases, sure, but not in a safe way for every usecase that can be thought of. And neither Erlang nor Elixir (nor the latest BEAM language, I forgot the name), luckily, try to do that. They give this controller to the developer and let them deal with the decision of how and when to use concurrency. They just try to make that as easy as possible, but they don't try to make sync and async code look and be the same.