[armitron]

"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."

I don't see how this follows. Async/await is a disaster in every way, M:N threading (which Goroutines are an implementation of) is the way to go. Not only does one get sane concurrency but also parallelism. Look at Ada tasks and Erlang processes for writing parallel code with critical requirements of correctness and efficiency.

[kristoff_it]

Goroutines (and stackful coroutines in general) require a runtime. Go has to sprinkle suspension points everywhere in the machine code (to prevent starvation) and when it needs to grow a goroutine stack, it also needs to know how to adjust every single relevant pointer in the entire program's memory to point to the new stack location.

This is not something that a systems programming language would want to do. I agree with your point that structured concurrency is good and preferable for high-level languages, but it's not an absolute better choice when you start thinking about the details, like you have to do in a systems programming language.

[socialdemocrat]

Agree, while I prefer the Go model from a usability perspective, I don't think that is the way to go for a language such as Zig. Zig seems to have done a really good job within the boundaries set by a language which aims for minimal level of abstraction.