[DixieDev]

This article was my first exposure to async in Zig, and I find it rather at odds with the "No hidden control flow" selling point of the language.

  fn foo() void {
    bar();
    std.log.info("bar is finished");
    baz();
    std.log.info("baz is finished");
  }

I cannot just look at this function and know what it's doing and how to use it. If bar()'s implementation contains a suspend or await keyword then this won't compile when called from main() unless its call is prefixed with async, and even if I do so then I also have to make sure I resume foo enough times for bar (or baz) to finish too. Am I missing some key detail here? It seems out of place compared to many other language features.

[DixieDev]

My original reply is kind of sloppy, here's a snippet to better illustrate my confusion: https://gitlab.com/-/snippets/2290425

Specifically, examine this:

  fn foo() void {
    bar();
    std.log.info("foo() is finished", .{});
  }

It looks dead simple, but it's a pain in the butt to use because it's actually async, and you can know neither that nor how to get this function to actually finish without looking inside of bar().

[samatman]

You can't know this function will actually finish without looking inside of bar() in any Turing Complete language, because this is the Halting Problem.

Not in a trivial way either. A good async language will never let std.log.info print until/unless bar resumes.

The difference between a "blue foo" and a "red foo" is also subtler than we pretend it is. Both will finish eventually, unless they don't, and both may be paused for as long as the OS wants in any preëmptive operating system.

[DixieDev]

Ok, sure, there are a whole bunch of reasons that my function might not actually finish. In this case, though, it's specifically not finishing due to invisible compile-time additions Zig is making to the function I've written.

They could instead require me to explicitly write `await bar();` within foo(), and I could find comfort in the "no hidden control flow" tenet of the language once more. I recognise now that this would break the colour-blindness of their async implementation and that this is a pretty significant trade-off, but my perspective remains that this breaks one of the rules they've laid out on their homepage.

[lostmsu]

Can I call foo from main and expect, that by the time program completes, info is logged? If not, I agree with GP - that is a very bad design.

[samatman]

No, you can't, not without knowing what is inside of bar().

bar() could contain an infinite loop. bar() could call rand() and try to reference the null pointer 1 in n times. bar() could issue forth nasal demons to haunt you. bar() could call os.exit. bar() could recurse until the stack is exhausted. bar() could suspend and not resume. The OS could kill bar() from outside before it returns.

Who knows what shadows lurk within a function's stack frame?

Run it and find out.

The invariant which needs to be preserved here is that if bar() returns, the log will print, and equally important, if bar does not return, the log will not print.

That's what a good async system can preserve without knowing what's inside bar.

[lostmsu]

OK, maybe I need to rephrase my question: if I do this in main, am I guaranteed to have "main" printed after "foo() is finished"

    foo();
    std.log.info("main", .{});

[kristoff_it]

That's how it works in Zig. Calling an async function like this will also await it.

[DixieDev]

Within main(), your snippet will give you an error at compile time "function with calling convention 'Inline' cannot be async". In my snippet foo() is invoked in an async context using the async keyword, and when foo() suspends (due to it awaiting bar()) control will be returned to main(). If you change your first line from

  foo();

to

  _ = async foo();

Then your program will compile and your log is not going to be prevented by Zig's async shenanigans.

[samatman]

I would consider that necessary, but not sufficient, to call a particular async system "good", yes.

[mkishi]

That seems to be the same kind of confusion I ran into the last time I tried to do async in Zig. I also had trouble figuring out who was responsible for keeping track of async frames.

The details are not fresh, but it went something like: if a function called an async function like so `the_frame = async foo();`, you couldn't really reliably `resume the_frame;` unless you were responsible for all suspend points hit inside `foo`. If `foo` tried to call some other function `bar` you had no idea had a suspend point, you couldn't resume the frame anymore since you'd need to resume the inner frame instead.

So, yeah, they were colorless as in you could call any function you wanted and they don't advertise suspend points or async usage, but they are actually colorful inside and calling the wrong color breaks things.