Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig: Upcoming release postponed two more weeks and lacks async functions

ziglang.org

Post reply on HN
Print view View original

41–50 of 62 posts

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#41

Post by chriswarbo »

Is there a reason async/await is being implemented specifically, rather than some more generally-useful primitive (like delimited continuations, algebraic effect handling, functor/applicative/monad, etc.[0])?

When it comes to e.g. memory management, Zig tries to be unopinionated and allow different implementations to be implemented as desired; so it seems odd to bake-in something like async/await (even if the execution strategy of those computations is up to the user).

I've seen this happen in many high-level languages (JS, Python, PHP, etc.), which I mostly attribute to (a) ignorance of those generalisations, and (b) a band-wagon effect. The unfortunate result in those languages is a bloated mess of try/catch, async/await, for/yield, apply/return, etc. and all of their O(n!) possible interactions; which could have instead been implemented as libraries on top of a single primitive (e.g. shift/reset, or whatever)

[0]: AFAIK these are all equivalently expressive, and given one it's easy enough to write the others as libraries.

PS: I recall asking this question when PHP added generators; I can't seem to find a bug report or mailing list post though...

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#42

Post by patmorgan23 »

DaiPlusPlus wrote: post #33
mtlynch wrote: post #6

Earlier quoted context omitted.

Oh, I just mean like filling the web with so much garbage that nobody can find your website.

It’s gotten really bad over the past few months, but even before GPT was a thing scummy operators just used Mechanical Turk or Fiverr. I don’t understand why Google is doing so poorly at filtering it out: for a concrete example, searching for terms relating to common semi-trivial problems when programming mainstream platforms like the web, Java, or C# will now result in low-quality, non-authoritative sites like Geeks…

The site: filter is your friend! Google should be smart enough that you don't need to use it but it is what it is.

You can even create your own custom Google search that only returns results for domains that you list. So you could put stack overflow, reddit, and a bunch of reference sites (like mdn) and have super high quality search results.

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#43

Post by DaiPlusPlus »

patmorgan23 wrote: post #42
DaiPlusPlus wrote: post #33

Earlier quoted context omitted.

It’s gotten really bad over the past few months, but even before GPT was a thing scummy operators just used Mechanical Turk or Fiverr. I don’t understand why Google is doing so poorly at filtering it out: for a concrete example, searching for terms relating to common semi-trivial problems when programming mainstream platforms like the web, Java, or C# will now result in low-quality, non-authoritative sites like Geeks…

The site: filter is your friend! Google should be smart enough that you don't need to use it but it is what it is. You can even create your own custom Google search that only returns results for domains that you list. So you could put stack overflow, reddit, and a bunch of reference sites (like mdn) and have super high quality search results.

I already do that when I can - but I'm more concerned about the legions of beginner-to-intermediate-level "coders" out there who will be learning outdated (if not woefully insecure) programming habits from those low-quality sources, which comes back to bite us all because, like it or not, companies hire people on the basis of how cheap they are, not about how competent and socially-responsible they are.

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#44

Post by bsder »

wredue wrote: post #40
DaiPlusPlus wrote: post #34

Earlier quoted context omitted.

> Lots of language do not have guaranteed to be called at a specific time “destructors”. Those tend to be GC languages though, where deterministic execution is not a hard requirement.

Sure, but this is also what defer is for. There isn’t implicitly called destructors because the languages mantra is “no hidden control flow”. RAII et semantics is almost entirely hidden control flow that you just have to “know”. Lots of people hate when they need to “just know” things to fully parse the code they’re reading. You’re free to dislike those decisions, of course. Personally, I like the target of no hidden…

I have a love/hate with this.

The big problem with defer/errdefer is that I have no way to mark a function as "This function always needs a defer after it and the compiler needs to yell at me if it doesn't exist."

It's also sometimes really hard to scope your defer/errdefer correctly. You may have to twist your code inside out because defer/errdefer ends at a block scope while your variable may not (via: "break :blk varname;").

This all bites so hard for things like reference counting. The bugs ... the bugs ...

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#45

Post by kprotty »

chriswarbo wrote: post #41

Is there a reason async/await is being implemented specifically, rather than some more generally-useful primitive (like delimited continuations, algebraic effect handling, functor/applicative/monad, etc.[0])? When it comes to e.g. memory management, Zig tries to be unopinionated and allow different implementations to be implemented as desired; so it seems odd to bake-in something like async/await (even if the executi…

Zig's async manages the coroutines intrusively: It generates the state machine type, you provide the memory for where an instance of one runs, and you manage resuming it until completion. Similar to Rust's Futures, it's pretty unopinionated in how you manage them so it works everywhere (i.e. freestanding). Could you clarify (or provide more reading on) how the other systems like delimited continuations, algebraic effects, and monads differ from Zig async + how they could be adapted in a similarly unopinionated/low-level way?

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#46

Post by kprotty »

laserbeam wrote: post #32
Dwedit wrote: post #25

Earlier quoted context omitted.

How the heck would that even work... In C#, they implement Await/Async by converting the function into a Class, just like when you use 'yield return'. Control flow is all over the place. Zig is so strict about "no hidden control flow" that you can't even have destructors (code which runs when a variable goes out of scope)

Yup. The lack of destructors means that at the time there wasn't an agreed upon way to cancel an awaitable function. Async/await in zig was cool, but there's a reason why it's described as an experimental feature in the article.

Destructors don't seem to be the best place to implement cancellation for async functions: Rust async is going through a phase where the community is realizing it would be nice to have async destructors or non-cancellable async functions to avoid introducing unnecessary overhead like concurrent reclamation, reference counting, and dynamically allocated memory for things that would otherwise be done statically using structured concurrency.

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#47

Post by continuational »

kissgyorgy wrote: post #11
ksec wrote: post #4

Why Async, especially considering Zig intends to be something like a High Level "portable Assembly"?

Zig's async implementation is the best of any languages, because you can run them without an event loop and in that case they will be simply synchronous. This completely eliminates the function coloring problem.

It absolutely doesn't, because it changes the semantics of what's being called, introducing deadlocks.

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#48

Post by Nullabillity »

lvass wrote: post #17
xxpor wrote: post #13

Earlier quoted context omitted.

Usually the coloring problem IME goes the other way: you want to run a synchronous/blocking function in an async context. How does Zig deal with that?

Function calls?

And now you're blocking the event loop.

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#49

Post by lvass »

Nullabillity wrote: post #48
lvass wrote: post #17

Earlier quoted context omitted.

Function calls?

And now you're blocking the event loop.

If you chose to use cooperative concurrency, it's because you can make it cooperate. Use preemption otherwise.

Re: Zig: Upcoming release postponed two more weeks and lacks async functions

#50

Post by chriswarbo »

kprotty wrote: post #45
chriswarbo wrote: post #41

Is there a reason async/await is being implemented specifically, rather than some more generally-useful primitive (like delimited continuations, algebraic effect handling, functor/applicative/monad, etc.[0])? When it comes to e.g. memory management, Zig tries to be unopinionated and allow different implementations to be implemented as desired; so it seems odd to bake-in something like async/await (even if the executi…

Zig's async manages the coroutines intrusively: It generates the state machine type, you provide the memory for where an instance of one runs, and you manage resuming it until completion. Similar to Rust's Futures, it's pretty unopinionated in how you manage them so it works everywhere (i.e. freestanding). Could you clarify (or provide more reading on) how the other systems like delimited continuations, algebraic eff…

> Could you clarify (or provide more reading on) how the other systems like delimited continuations, algebraic effects, and monads differ from Zig async + how they could be adapted in a similarly unopinionated/low-level way?

The key requirement for all these is an ability/API to defer and resume execution (indeed, delimited continuations are sometimes described as "resumable exceptions"). In higher-level languages we'd just assume the presence of first-class functions/closures, and use those to describe these features. I'm less familiar with how that looks in a very low-level language like Zig, however these "async frames" appear (to my naïve eyes) to be analagous; hence why I'm interested whether one of those more-general primitives could be provided instead (the answer might be no!).

As for clarification on those features, here's a quick attempt. Firstly, note that all of these approaches are basically APIs to construct, consume, and combine (deferred) computations: they are unopinionated on how those computations get run (e.g. the user could supply a "main loop", or whatever).

Delimited continuations are like exceptions, except the stack (AKA continuation) is passed to the handler, which may choose to resume it. We can implement coroutines/async/yield/etc. by having handlers which put their continuation in a queue and pop off some other one to resume instead; we can get data parallelism by resuming a continuation many times; we can get backtracking by remembering old continuations and trying them again; we can get parsers, probabilistic programming, nondeterminism, etc. https://en.wikipedia.org/wiki/Delimited_continuation

Algebraic effects are similar, but defunctionalised: i.e. they represent control flow with datatypes, and are "interpreted" by a user-specified function.

Applicative is an API for combining two computations concurrently, e.g. the product of Foo and Bar is a single computation yielding a pair of results. Monad can likewise combine sequentially, where Bar depends on the result of Foo. These feel more abstract, but are equivalent to the above e.g. see https://okmij.org/ftp/continuations/implementations.html https://reasonablypolymorphic.com/#understanding-freer-monad...

Post reply on HN