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

Zig: Build System Reworked

ziglang.org

Post reply on HN
Print view View original

171–180 of 263 posts

Re: Zig: Build System Reworked

#171

Post by tarruda »

brabel wrote: post #24

I just upgraded some code to Zig 0.16.0 and I am actually really happy with the results. It impacted A LOT of things, but the changes were actually very good and seems to have set the language for a bright future, especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop! If you haven't tried Zig since 0.1…

> especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop!

I had some trouble understanding how the async/await mechanism works:

  var foo_future = io.async(foo, .{args});
  defer if (foo_future.cancel(io)) |resource| resource.deinit() else |_| {}

  var bar_future = io.async(bar, .{args});
  defer if (bar_future.cancel(io)) |resource| resource.deinit() else |_| {}

  const foo_result = try foo_future.await(io);
  const bar_result = try bar_future.await(io);
My assumption is that calling io.async using an event loop implementation of IO, it will internally start a "task" (or whatever it should be called) and that the future is a handle to it. So far so good.

The part that I don't understand is what happens when you call future.await(io). Will the IO implementation somehow suspend the current function and resume once the future is resolved? If so, does that mean that every function in zig is a stackless coroutine?

Re: Zig: Build System Reworked

#172

Post by jasonjmcghee »

tarruda wrote: post #171
brabel wrote: post #24

I just upgraded some code to Zig 0.16.0 and I am actually really happy with the results. It impacted A LOT of things, but the changes were actually very good and seems to have set the language for a bright future, especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop! If you haven't tried Zig since 0.1…

> especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop! I had some trouble understanding how the async/await mechanism works: var foo_future = io.async(foo, .{args}); defer if (foo_future.cancel(io)) |resource| resource.deinit() else |_| {} var bar_future = io.async(bar, .{args}); defer if (bar_future…

For future reference you can format code on hn with a newline first then indenting each line by 2+ spaces. (Rather than triple tick)

Re: Zig: Build System Reworked

#173

Post by NewsaHackO »

jmull wrote: post #167
NewsaHackO wrote: post #122

Earlier quoted context omitted.

But this goes to my second point; it seems like Zig wasn’t open to any compromise about the solution that Bun submitted and one they built in house. Is it the Zig culture to reject a pull request like that wholesale? It’s really odd for them to have such a flippant attitude and not to even try offer ways that they could use the pull request or things that they need to tweak to make it more inline with what they want.…

A large, complex, unasked for PR is pretty likely pointless to throw at any serious project. (Well, it's pointless if your goal is to merge something.) Working together is a two-way process. To land a big change, the bun people probably needed to have been working/coordinating with the zig people throughout. E.g., zig outright cannot accept PRs that break the language in unplanned ways and any conflicts with the road…

Of course, and it is expected that large pull requests/RFCs are iterated on. I will not believe Bun seriously asked for a pull request to be merged with absolutely no expectation of back and forth discussion. But this isn’t what happened. The whole reason everyone thought it was rejected by Zig because Bun used LLM to generate it was because they responded in a way that someone would if they didn’t want a certain pull request accepted under any circumstances. Which is my point; it I just insane that their largest project submitted a pull request, and they just rejected it with prejudice, gave some statement saying the real and potentially fixable reasons why, then turn around and say we don’t want your help, we are doing this in house.

Re: Zig: Build System Reworked

#174

Post by Arch485 »

onlyrealcuzzo wrote: post #123
IshKebab wrote: post #47

Zig has so many compelling features, and I'd even be willing to give up Rust's near-perfect memory safety in some cases. But the one thing that really put me off is string handling. It's just so super tedious. I like being able to finely manage individual string memory allocations, but I really don't want to have to do it all the time . RAII is great; I wish they'd use some light (optional) RAII for strings and conta…

> RAII is great; I wish they'd use some light (optional) RAII for strings and containers etc. Is it not possible to build a wrapper that does this? It seems like it should be.

It is. I definitely agree that strings in Zig can be tedious, but the upside is that if you need it, you can build a string library that does everything you want it to do, in the way you want.

For comparison, while Rust offers a very rich string library, it's also very strict about what you can/cannot do with strings, so if your use case falls outside of that you're out of luck. With Zig, you can pretty easily roll your own and make it do what you want. (and when Zig is post 1.0, I imagine there will be some very nice pre-made string libraries by the community etc.)

Re: Zig: Build System Reworked

#175

Post by tarruda »

jasonjmcghee wrote: post #172
tarruda wrote: post #171

Earlier quoted context omitted.

> especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop! I had some trouble understanding how the async/await mechanism works: var foo_future = io.async(foo, .{args}); defer if (foo_future.cancel(io)) |resource| resource.deinit() else |_| {} var bar_future = io.async(bar, .{args}); defer if (bar_future…

For future reference you can format code on hn with a newline first then indenting each line by 2+ spaces. (Rather than triple tick)

Fixed it. thanks!

Re: Zig: Build System Reworked

#176

Post by defen »

ozgrakkurt wrote: post #130
epolanski wrote: post #5

This sounds like great news, Zig's compilation times are already terrific and this is going to only make them better.

Just creating a file with dummy test like if (2 * 2 != 5) { @panic("fail"); } And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer. It also keeps taking the same amount of time every time I do it when I modify that file. Using 0.16 (or master) version so my toolchain isn't old and I'm on linux. Zig is super nice to use as a language but the compiler/stdlib isn't developed conservatively…

> Just creating a file with dummy test like

> if (2 * 2 != 5) { @panic("fail"); }

> And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer.

What kind of computer are you on? I just ran that test (latest master build, first run):

   ~ % time zig test file.zig -OReleaseSafe
   file.zig:1:17: error: expected type expression, found '{'
   if (2 * 2 != 5) { @panic("fail"); }
                ^
   zig test file.zig -OReleaseSafe  0.03s user 0.44s system 505% cpu 0.094 total
Granted I'm on an M4 Mac but I wouldn't expect another system to be 20x slower.

Re: Zig: Build System Reworked

#177

Post by ozgrakkurt »

defen wrote: post #176
ozgrakkurt wrote: post #130

Earlier quoted context omitted.

Just creating a file with dummy test like if (2 * 2 != 5) { @panic("fail"); } And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer. It also keeps taking the same amount of time every time I do it when I modify that file. Using 0.16 (or master) version so my toolchain isn't old and I'm on linux. Zig is super nice to use as a language but the compiler/stdlib isn't developed conservatively…

> Just creating a file with dummy test like > if (2 * 2 != 5) { @panic("fail"); } > And running `zig test file.zig -OReleaseSafe` takes a couple seconds on my computer. What kind of computer are you on? I just ran that test (latest master build, first run): ~ % time zig test file.zig -OReleaseSafe file.zig:1:17: error: expected type expression, found '{' if (2 * 2 != 5) { @panic("fail"); } ^ zig test file.zig -ORelea…

I’m on ryzen 7600 cpu and linux cachyos.

Edit: I just realised you have a compilation error so the compiler isn't doing much work

Re: Zig: Build System Reworked

#178

Post by cfiggers »

scuff3d wrote: post #165
xngbuilds wrote: post #50

After watching Andrew Kelley's interview video makes me want to pick up Zig: https://www.youtube.com/watch?v=iqddnwKF8HQ

I have a lot of respect for Andrew, and I really enjoy Zig, but God that interview was awful. Andrews answers were fine, but the whole thing felt very sycophantic.

I didn't get the same impression. I'm curious to know what created that feeling for you. Perhaps I'm turning a blind eye to something or other?

Re: Zig: Build System Reworked

#179

Post by addaon »

Decabytes wrote: post #149

There is an idea I've been kicking around for a long time, which I'll just call dual programming. The idea is to develop a stack that consists of just two programming languages, 1 higher level language, and one lower level language. You are supposed to do as much programming as you can in the high level language, and only drop into the low level language as needed. The problem is that unless you already know a low le…

Objective-C and C?

Re: Zig: Build System Reworked

#180

Post by kristoff_it »

tarruda wrote: post #171
brabel wrote: post #24

I just upgraded some code to Zig 0.16.0 and I am actually really happy with the results. It impacted A LOT of things, but the changes were actually very good and seems to have set the language for a bright future, especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop! If you haven't tried Zig since 0.1…

> especially with the new IO mechanism which allows supper efficient code that looks good whether it's implemented single-threaded, multi-threaded or just via an event loop! I had some trouble understanding how the async/await mechanism works: var foo_future = io.async(foo, .{args}); defer if (foo_future.cancel(io)) |resource| resource.deinit() else |_| {} var bar_future = io.async(bar, .{args}); defer if (bar_future…

> If so, does that mean that every function in zig is a stackless coroutine?

No and yes.

If you're using Io.Threaded, then the concurrency model is multithreading and calling Future.await will block your thread on a OS futex.

If you're using Io.Evented, then the concurrency model is green threads / fibers and calling Future.await will suspend the current green thread by yielding (swapping CPU state with another fiber).

Zig currently does not support stackless coroutines so today you can't have that, but we used to have them (pre self-hosted compiler), and there's an accepted proposal to bring them back, in which case any function that calls await, or that otherwise has a suspension point, would have to be transformed into a stackless coroutine by the compiler, yes. The plan is for that to happen transparently without requiring an `async` annotation in the function signature, like we already did in the past.

This is an old post of mine that explains how that worked at a high level: https://kristoff.it/blog/zig-colorblind-async-await/

Post reply on HN