To be pedantic, I would reconsider if/when Zig gets native concurrency support, which may or not use the async/await paradigm. In my perfect world, I would personally rather see something more akin to Go’s channels, as I am not a fan of function coloring.
I think goroutines are preferable in that context because async/await is a much lower level tool that is easy to misuse, but when it comes to writing code with critical requirements of correctness and efficiency, you need async/await and you need Zig’s philosophy that we all should strive to write robust , optimal , and reusable software.
This is a very compelling point that I didn’t think of. So long as function-coloring is a non-issue, I wouldn’t mind async/await, it is an intuitive pattern to use.
async/await also has a ‘hidden complexity’ (or even hidden-control-flow) problem, e.g. the function bodies produced by the compiler have not much in common with the sequential code you’re writing since the sequential code is split into a switch-case state machine with an imlicit context parameter.
Debuggability is also a concern (I think both approaches need special debugger support).
IMHO: I would like to see that most Zig libraries simply using completion callbacks for asynchronous code as the least common denominator, since completion callbacks are the common base that can then wrapped in async/await, green-threading or multithreading code (e.g. such a Zig library would be usable with all those concurrency and parallelism concepts)
