Zig also uses colored functions here, but introduces a mode to globally(?) block on every async call. While you can certainly do that, I'm not sure if that is a great language feature to have, to be honest - at least if I don't misunderstand their idea.
In Rust, you color functions at declaration time through special syntax, and, depending on the color of the caller, you have to use either block_on() or .await to get a value out of a call to an async function.
That's not the case for Zig. There's no special decorator, no block_on/await distinction, and regular calls will return the expected value by implicitly awaiting (in case evented mode is enabled). A callsite may decide not to implicitly await the result by using the async keyword, which then requires an explicit await on the returned promise.
Well yeah - you can do exactly the same in other languages, such as Scala. It just isn't a good idea. They explain it themselves:
> there’s plenty of applications that need evented I/O to behave correctly. Switching to blocking mode, without introducing any change, might cause them to deadlock
zig doesn't switch. It's statically typed, and I think (not 100% sure) it detects if you have called a function with the async keyword and when that happens it triggers compiling a second version of the function with async support, so there are actually two versions of the function floating around in your binary. Since zig is itself a parsimonious compiler, if that's never in a codepath (say it's provided by a library), it doesn't get compiled. The reverse is true, too, if you ONLY call a function with the async keyword, it doesn't compile the non-async version. Again, with the caveat that I think that's what's going on.
reply