> On a type-theoretic level, it’s like entering a global async monad, which is roughly the structure that Go and Erlang have. This is the most concise summary

> On a type-theoretic level, it’s like entering a global async monad, which is roughly the structure that Go and Erlang have. This is the most concise summary of what Zig actually does! Thank you. I always felt it was a little off, but it makes sense when you think about it in terms of "Zig makes all of your functions red, even if you don't want them to be." In fact, in the article linked above, it says this in the FAQ: > Q: SO I DON’T EVEN HAVE TO THINK ABOUT NORMAL FUNCTIONS VS COROUTINES IN MY LIBRARY? > No, occasionally you will have to. As an example, if you’re allowing your users to pass to your library function pointers at runtime, you will need to make sure to use the right calling convention based on whether the function is async or not. You normally don’t have to think about it because the compiler is able to do the work for you at compile-time, but that can’t happen for runtime-known values. So in essence, Zig actually is still colored, but the compiler handles for you what it can.