Forgive my ignorance, for I am a lowly web-developer, but I’m wondering why Zig pursued async at all, given the goal of having a semantically simple language.
I am familiar with the JS event loop, and have a basic understand of golang’s scheduler.
My (potentially wrong) understanding is that JS, Rust, C# and Zig(?) all use the same “futures” style of concurrency, wherein you have one task going at a time, but if you hit a wait point (I/O, network, etc.) the program can start a new task, and won’t go back to the previous one until it’s current task finishes or has to wait itself.
With this in mind, I figured the best options for concurrent programs was to either:
- Use a language specifically designed for it (golang, elixir/erlang)
- Roll your own event loop using File descriptors and/or interrupts.
I’ve done #2 once with ZMQ, and although I’m sure it wasn’t perfect, it was easier than I thought and more than sufficient for my piddly workload.
Zig’s implementation seems very well thought out, and I know the Zig team are very smart people who think their decisions through, and the Zig specs async seem really solid, esp. the ban on function coloring.
Interested to hear peoples’ takes. 