4 ms·
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
by cygx 5y ago
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.
edit: fix caller/callee typo
- valenterry 5y agoWell 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
- dnautics 5y agozig 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.
- dnautics 5y agoCorrection: my understanding is incorrect, zig does not compile two versions of the functions. Nonetheless, it does not switch.
- valenterry 5y agoWell, I'm quoting their own explanation...