4 ms·
Well said. Honestly I don't understand this "function coloring argument" at all in zig's context. Function is the smallest unit of logic. And function paramete
by rk06 1y ago
Well said. Honestly I don't understand this "function coloring argument" at all in zig's context.
Function is the smallest unit of logic. And function parameter is the fundamental way to control it.so, in theory, __A function parameter is the smallest possible design choice you have to control async vs sync__
There is no way to reduce it further. As you need to encode this somehow, otherwise it will be implicit and very hard to debug.
functions can compose. Function parameters can be composed. Making this a solid design choice.
Zig has somehow achieved this feat of decomposing async/sync to a single parameter. This deserves an ovation
Other langs should take note.
- metaltyphoon 1y ago> in theory, __A function parameter is the smallest possible design choice you have to control async vs sync__ So we are just going to forget Go exists?
- rk06 1y agoDisclaimer: I have not used golang, so i might be wrong. as per my understanding, golang has it implicit. Like there is no way for a developer to tell if code will run under async context or not.
- throwawaymaths 1y agono, in golang (and erlang) every function is async, and there are implicit yield points in "well-known" places. for erlang it's every function call boundary, for golang its the end of functions. in the past this was a problem for go because a for (ever) loop could block your cpu process. not a problem for erlang since all forever loops must be tco function calls (inducing a yield at each interation)