Here too? Never mind function colouring, async/await itself is a feature that infects entire languages.

Such a terrible abstraction of concurrency for our 1970-style languages. Zig doesn't have strings because they're too high level, but async/await is fine.

From what we know their async/await should be noticeably distinct from the usual, otherwise the previous revert was for nothing.

I still can't find a decent explanation as to why zig, a C replacement needs to have Async built in by default. I actually think this should belong to a higher level abstraction.

Zig doesn't have to have it, but in Zig's specific case it can offer a surprisingly innovative implementation of it. The grandparent post mentioned how async/await infects languages (it does) and Zig is in a unique position where this would be not as true. Note that async/await has to gain a lot by being "built in" as opposed to a pure userland thing, as it basically is used to rewrite function bodies and mess with calling conventions.

As for the correct level of abstraction of async/await I believe that it's actually a very low-level primitive that should only be offered in low-level languages as it's very footgunny to use in high-level languages and generally worse than actors/csp.

Unfortunately I think this is not the case -- it might just be that the async/await issue is getting pushed into the next milestone tag with each release. In the most recent roadmap video[1] Andrew said that the main focus right now is compilation speed, and that async/await specifically was going to take a long time. My memory is that he says something about how it doesn't work well with LLVM and is generally a hard problem that they would prefer to do correctly instead of quickly.

[1]: https://www.youtube.com/watch?v=5eL_LcxwwHg

You are absolutely right, he did indeed share those thoughts. I do remember now! Thanks