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

191–200 of 263 posts

Re: Zig: Build System Reworked

#191

Post by ngrilly »

Arch485 wrote: post #174
onlyrealcuzzo wrote: post #123

Earlier quoted context omitted.

> 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 y…

But I don't think you can implement RAII in Zig?

Re: Zig: Build System Reworked

#192

Post by forrestthewoods »

dzbarsky wrote: post #188
forrestthewoods wrote: post #166

My kingdom for Zig to have an official mechanism to emit the Linux library stubs. Zig’s ability to crosscompile and target arbitrary versions of glibc is PURE MAGIC. I leverage this magic in an unrelated C++ build system. But I have to hack around to get those library stubs from Zig. Would love it to be an official output.

Check out https://github.com/cerisier/glibc-stubs-generator

Interesting. So here's my pretty hacky take on it.

https://github.com/forrestthewoods/anubis/blob/983d8a1b9ea5e...

It invokes zig on a dummy C or CPP file. Then it scrapes the output looking for specific files.

C: crt1.o, libm.so, libpthread.so, libc.so, libdl.so, librt.so, libld.so, libutil.so, libresolv.so, libc_nonshared.a, libcompiler_rt.a

C++: crt1.o, libc++abi.a, libc++.a, libunwind.a, libm.so, libpthread.so, libc.so, libdl.so, librt.so, libld.so, libutil.so, libresolv.so, libc_nonshared.a, libcompiler_rt.a

Zig is also a god send in that it has all the generated glibc header bullshit for Linux.

I've got a system that is able to cross-compile ffmpeg for Linux from Windows. Which is a shockingly painful and rare capability. Linux userspace design is so so so so so bad. So embarrassingly bad.

Andrew Kelley is a damn saint for the mountains he moved for Zig. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Now I just wish some of this capability was exposed in a slightly more formal capacity so that it could be leveraged by the broader community :)

Re: Zig: Build System Reworked

#193

Post by xyzsparetimexyz »

latexr wrote: post #185
xyzsparetimexyz wrote: post #61

Earlier quoted context omitted.

> But nothing gets in your face how to use the programming language "correctly". It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me

> It doesnt let you have unused variables Andrew Kelly on that: https://www.youtube.com/watch?v=iqddnwKF8HQ&t=2927s Looks like you might be able to get rid of the error easily with annotations.

So your ice turns 'let unused = func();' into 'let _ = func();' automatically? Okay but then do I later have to grep for 'let _' to find all these unused variables and delete them? This is silly and a has consequence of zig not having any system for warnings

Re: Zig: Build System Reworked

#194

Post by trueno »

foresto wrote: post #170
xyzsparetimexyz wrote: post #61

Earlier quoted context omitted.

> But nothing gets in your face how to use the programming language "correctly". It doesnt let you have unused variables and theres no multiline comment support. These are fairly significant productivity issues for me

> It doesnt let you have unused variables Ugh. This is something I hate about Go. I would be happy to have unused variables generate warnings, but as errors, they turn the toolchain into an adversary. It's common for me to temporarily comment out a variable's use when developing new code, as I experiment with ideas. It's even more common when working in unfamiliar code, such as tracking down a bug or incrementally ad…

> Ugh. This is something I hate about Go

Yeah it drives me insane. Working in any ide's golang lsp/plugin that tries to solve this for you every time you hit save also drives me insane. Feel like something is lost experiencing/learning/becoming masterful at a language when these types of decisions get automated while you're hand crafting.

I actually really valued my exploration into C where if i did that, id get a fat warning on compile, but I could still proceed to test my stuff. When I'm ready to commit to some cleanup efforts which is usually a headspace-thing, then I go cruise around and cleanup unused variables.

Re: Zig: Build System Reworked

#195

Post by scuff3d »

cfiggers wrote: post #178
scuff3d wrote: post #165

Earlier quoted context omitted.

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?

There's a lot of little things that just added up, but I think the clearest example was the exchange regarding Andrew's pay from the foundation. I don't have an issue with him being paid for the work, or the amount he's taking, I would be surprised if anyone really did, but the way the interview asked the question came off as "Oh you're only making x? You should be paid so much more", and Andrew even commented in it saying "...it sounds like you're implying I deserve more...". I'm of course paraphrasing, but that's the impression I walked away with.

The questions also had a tendency to be somewhat shallow. There were a lot of places where it felt like the interviewer was queuing Andrew to respond to criticism or explain controversial choices made for the language or tool chain, but the interviewer doesn't really follow up on them are point out what the issues might be.

It might have been expectations I guess. I was hoping for an interesting technical interview and instead it seemed like a fluff piece.

Re: Zig: Build System Reworked

#196

Post by geodel »

NewsaHackO wrote: post #129
geodel wrote: post #112

Earlier quoted context omitted.

> The fact of the matter is one of the biggest projects that used Zig thought that the devX was so bad that they opted to rewrite their entire 1M LOC project into a different language. That is not the fact of matter. The fact is it got bought by Anthropic. And in larger scheme of things Bun is one example Claude capabilities of translation. And even if doesn't work, it just a part of Claude desktop stack so still hav…

Not really, if it doesn’t work then it will hurt their flagship desktop app’s stability, which would negatively affect their placing in an already cutthroat AI arms. Claude Code is the few business asset that Claude has the least moat compared to other providers( even open source). They can’t afford to be sloppy and use a buggy JS engine.

Huh, I don't know which world you live in. In my world trillion dollars companies regularly release absolute crap of the software that hardly affects their industry usage or popularity.

In case anyone is not following the AI tool's biggest growth is in enterprises. And usability, quality or stability is measured very differently there compared to individual users. In my last 20 years of experience of using enterprise software and tools being third rate is never any issue.

Re: Zig: Build System Reworked

#197

Post by defen »

ozgrakkurt wrote: post #177
defen wrote: post #176

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

I used exactly what you posted; should I make an empty hello-world type of file instead?

Re: Zig: Build System Reworked

#198

Post by tarruda »

kristoff_it wrote: post #180
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…

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

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

If the compiler will treat functions that call a library function (Future.await) as special and change how the call site is compiled, why not just have an `await` keyword that when present will convert it into a state machine that can be suspended/resumed?

In other words: What is gained by not having a keyword that changes how a function is emitted if the compiler will change it anyway based on detection of a library call?

Re: Zig: Build System Reworked

#199

Post by frail_figure »

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…

Neovim comes to mind. It uses clang as the core, and luajit as the extension layer on top.

Re: Zig: Build System Reworked

#200

Post by satvikpendem »

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…

Or just use one language that does both high level and low level programming well, such as Rust. I use it for everything now as I haven't found anything it can't do yet, especially with its OCaml like type system.
Post reply on HN