Zig's new I/O: function coloring is inevitable? • Hacker News Board

Re: Zig's new I/O: function coloring is inevitable?

#81

Post by naasking » Tue, Jul 15, 2025, 7:47 PM UTC

SkiFire13 wrote: post #79

naasking wrote: post #78

Earlier quoted context omitted.

> They are akin to making everything async, which proves my point: you have to make everything of one kind in order to solve the problem. You can use ordinary direct style compilation, but all references to stack values simply have to be relative offsets, then a simple implementation of shift/reset is just capturing context and copying stack fragments, which you can do using setjmp/longjmp in C (although there are be…

> but all references to stack values simply have to be relative offsets Then such references are no longer pointers, and in order to have a generic reference (that can point to both stack memory and heap memory) you have to store additional data (which one of them it points to) and conditionally use the correct one any time you access it. This is a very invasive change to the memory model. > then a simple implementat…

> https://github.com/koka-lang/libhandle

Dropped the r somehow:

https://github.com/koka-lang/libhandler

> Sure, if everything has to be able to "wait" for the result of a continuation then you're forcing async support on everything.

If "forcing async support" doesn't mean that code has to change, or any other code in the call chain, then it's just meaningless pedantry.

Re: Zig's new I/O: function coloring is inevitable?

#82

Post by Rapzid » Wed, Jul 16, 2025, 12:43 AM UTC

woodruffw wrote: post #10

kristoff_it wrote: post #5

If you want to go down that route, any function that has, or doesn't have, any given resource is colored then. fn foo(db: *Db) !void { ... } fn bar() !void { ... } Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me. The virality of async await is that once you mark a function async, then you can only call it from another async function, which forces you to…

> Would you consider `foo` a blue function and `bar` a red function? That doesn't seem particularly helpful to me. In the sense of effect/capability typing, I think the answer is yes. "Coloring" isn't magical, it's just a way to describe effects. Those effect can be described by keywords (`async` in JS, `throws` in Java, etc.) or special token parameters/types (what Zig does), but the consequences are the same: the e…

It's also not true you can't call an async function from a sync function. In C# and JavaScript You can, you just can't "await" it. There are a lot of details involved, but it's just not true that you can't call async from sync.

Re: Zig's new I/O: function coloring is inevitable?

#83

Post by throwawaymaths » Wed, Jul 16, 2025, 5:26 AM UTC

rk06 wrote: post #52

metaltyphoon wrote: post #44

Earlier quoted context omitted.

> 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?

Disclaimer: 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.

no, 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)