3 ms·

This would mean that there's no guarantee about the order in which your code will run, because your scheduler might decide to execute some unrelated code right

This would mean that there's no guarantee about the order in which your code will run, because your scheduler might decide to execute some unrelated code right in between any two lines. Therefore, you would need to deal with far more race conditions. Even in single-threaded languages, your entire state may change during a single asynchronous function call. By differentiating between synchronous code (i.e. code that needs to be run in a single slot) and asynchronous functions, you can immediately see where you need to account for unexpected state changes. (Yes, it's more complicated in multithreaded languages, but the main idea still holds because they usually all sync back to a single thread)

mikepurvis 5y ago
But per the original function colouring article (and summarized at the top of this one) several major parallel-first languages already do this, notably Go and Erlang. And it seems to work great for them.
- lmm 5y ago
  You can do it, but at a cost. Interop via the system ABI becomes much harder. You lose the ability to write high-performance blocking code, and reasoning about performance requires understanding a lot of details of the runtime. And to get to the grandparent's point, you have to find a way to protect yourself from the problems of shared-memory threading; Erlang does this by adopting a strict ownership model that's not directly tied to threads (actors), which forces you to structure your programs a particular way and makes certain things impossible. Go has a less strictly enforced model and ends up being quite prone to race conditions, but keeps it under control by discouraging writing large programs at all (in favour of the "microservice" style).