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

51–60 of 62 posts

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

#51

Post by anonymoushn »

chriswarbo wrote: post #50
kprotty wrote: post #45

Earlier quoted context omitted.

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…

I think you can implement delimited continuations in terms of async frames and memcpy (like in Lua you can implement call/cc in terms of the built-in coroutine library plus coroutine.clone). The language doesn't guarantee that this works though if you try to resume an async frame somewhere other than its original address.

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

#52

Post by jokoon »

generichuman wrote: post #24
jokoon wrote: post #21

I wish zig could be enabled for godot.

What do you mean by "enabled"? If you want to use Zig with Godot, you can! Just use GDExtension [0]. [0] https://docs.godotengine.org/en/stable/tutorials/scripting/g...

gdextensions are not easy to use

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

#53

Post by Hamcha »

mtlynch wrote: post #2

> I’m not on Twitter anymore - my goal is to instead channel that micro-blogging energy into regular blogging energy on my personal website as well as posting Zig project news here on ziglang.org. Cool, I like this! I realized last year that I was investing too much time into sharing things on Twitter that I'd subsequently forget about or be unable to find. Instead, I created a separate section on my personal blog fo…

I'm also trying to do my part in fixing my own and many other's overreliance on reddit comments for everyday problem solving and advice. I decided that every time I would write an decently sized explanation of something on Discord/Telegram, I would instead write a post and link it.

To make it as convenient as possible (every amount of friction would eat at my motivation) I made it using Obsidian Digital Garden [1]. It's a bit of a hassle to set up and the UI is annoyingly bad but it's pretty convenient (boils down to click to publish) afterwards.

1. https://dg-docs.ole.dev/

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

#54

Post by kprotty »

continuational wrote: post #47
kissgyorgy wrote: post #11

Earlier quoted context omitted.

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.

Zig async doesn't change semantics of how things are called. If something is called sequentially, it will execute sequentially with respect to itself, with or without async.

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

#55

Post by kprotty »

j16sdiz wrote: post #27
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?

They have await keyword. This is noop in sync mode

Did you mean the `nosuspend` keyword? It only asserts nothing suspends rather than there being a "sync" mode.

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

#56

Post by kissgyorgy »

continuational wrote: post #47
kissgyorgy wrote: post #11

Earlier quoted context omitted.

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.

It doesn't change the semantics, the documentation says: https://ziglang.org/documentation/0.10.1/#Async-Functions

"Async functions can be called the same as normal functions." Only when you have an event loop, the order async functions are running might be different because of the scheduling, but everything else is the same.

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

#57

Post by kprotty »

bsder wrote: post #44
wredue wrote: post #40

Earlier quoted context omitted.

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…

You can `errdefer/defer if` inside the blk, then x = blk:{}; defer use(x)` outside the block.

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

#59

Post by pjmlp »

DaiPlusPlus wrote: post #34
wredue wrote: post #29

Earlier quoted context omitted.

Huh? Lots of language do not have guaranteed to be called at a specific time “destructors”. Additionally, zig provides this functionality with defer and errdefer, giving you the ability to explicitly call a function at the end of scope.

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

Depends on the language, and the set of automatic memory management tooling available.

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

#60

Post by pjmlp »

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.

Except Modula-2 and Concurrent Pascal, among several others did it first, in the 1970's.
Post reply on HN