4 ms·
> Feels like this violates zig “no hidden control flow” principle. A hot take here is that the whole async thing is a hidden control flow. Some people noticed
by rdtsc 1y ago
> Feels like this violates zig “no hidden control flow” principle.
A hot take here is that the whole async thing is a hidden control flow. Some people noticed that ever since plain callbacks were touted as a "webscale" way to do concurrency. The sequence of callbacks being executed or canceled forms a hidden, implicit control flow running concurrently with the main control logic. It can be harder to debug and manage than threads.
But that said, unless, Zig adds a runtime with its own scheduler and turns into a bytecode VM, there is not much it can do. Co-routines and green threads have been done before in C and C-like languages, but not sure how easily the would fit with Zig and its philosophy.
- throwawaymaths 1y agohidden control flow means no control flow occurs outside of function boundaries, keywords, short circuiting operators, or builtins. i believe there is a plan for a asyncresume and asyncsuspend builtins that show the actual sites where control flow happens.
- int_19h 1y agoThey have plans for multiple implementations including green threads and stackless.
- rdtsc 1y agoThat's pretty neat. Thanks for pointing it out. The abstraction on top still async based and I agree it makes sense for Zig. But in general I don't like that abstraction. I like it when it's flipped around -- the abstraction is process/thread/green thread-like and sending messages or events around. Underneath it may involved having a few IO pollers with select/epoll/io_uring, a thread pool, etc. But the top level API doesn't handle promises, futures, callback, deferreds, etc. I am thinking of Go's goroutines, BEAM VM processes, or even plain threads or processes talking over the network or locally via queue.