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

Open-source Zig book

zigbook.net

Post reply on HN
Print view View original

351–360 of 426 posts

Re: Open-source Zig book

#351

Post by tamnd »

pelasaco wrote: post #275
tamnd wrote: post #263

Earlier quoted context omitted.

If you're doing it for real-world values, keep doing that. But if you want traction, writing in a "fancy" language is almost a requirement. "A database engine written in Zig" or "A search engine written in Zig" sounds much flashier and guarantees attention. Look at this book: it is defintely an AI slop, but it stays at the top spot, and there's barely any discussion about the language itself. Enough rant, now back on…

> For my personal usage, I'm working on replacing Docker builds for some Go projects that rely heavily on CGO by using `zig cc`. I'm not using the Zig language itself, but this could be considered one of its use cases. Hm, i can see a good use case when we want to have reproducible builds from go packages, including its C extensions. Is that your use case, or are you aiming for multi-environment support of your compi…

My use cases similar to this https://blog.afoolishmanifesto.com/posts/golang-zig-cross-co...

need to bundle a lot of C libraries, some using dynamic linking and some using static linking, and I need to deploy them on different operating systems, including some that are difficult to work with like RHEL. Right now the builds are slow because I use a separate Dockerfile for each platform and then copy the binary back to the host. With Zig CC I could build binaries for different platforms and architectures without using Docker.

Re: Open-source Zig book

#352

Post by [deleted] »

cryptocod3 wrote: post #301
rudedogg wrote: post #281

I submitted this and unfortunately it is likely AI generated. The authors github history suggests it at the very least, along with seemingly misunderstanding a reference to a Zig language feature (labeled blocks - https://zig.guide/language-basics/labelled-blocks/ ) in the project issues ( https://github.com/zigbook/zigbook/issues/4 ). I’m not sure how much value is to be had here, and it’s unfortunate the author was…

> if there are hallucinations Plenty. I assumed that the code examples had been cleaned up manually, so instead I looked at a few random "Caveats, alternatives, edge cases" sections. These contain errors typically made by LLMs, such as suggesting to use features that doesn't exist (std.mem.terminated), are non-public (argvToScriptCommandLineWindows) or removed (std.BoundedArray). These sections also surfaces irreleva…

[deleted]

Re: Open-source Zig book

#353

Post by tamnd »

virajk_31 wrote: post #276
tamnd wrote: post #266

Earlier quoted context omitted.

Yeah, you should. Zig is a trending language right now, and in the coming years many projects are likely to be rewritten in Zig instead of Rust (often referred to as "riiz").

Is this sarcasm? if yes I got your joke otherwise please enlighten me _/\_

I was half joking. Folks keep saying everything will get rewritten in Zig, so I played along with that. Nothing serious behind it.

With only half serious intent, I think only the real wizard types, like Jarred Sumner (Bun) and Mitchell Hashimoto (Ghostty), who understand both low level systems and higher level languages, should be writing big tools in Zig. The tough part in the next few years will not be building things, it will be keeping them alive if the authors step away or the ecosystems move in a different direction.

Re: Open-source Zig book

#354

Post by vipvip »

Klonoar wrote: post #112
eibrahim wrote: post #99

So many comments about the AI generation part. Why does it matter? If it’s good and accurate and helpful why do you care? That’s like saying you used a calculator to calculate your equations so I can’t trust you. I am just impressed by the quality and details and approach of it all. Nicely done (PS: I know nothing about systems programming and I have been writing code for 25 years)

> That’s like saying you used a calculator to calculate your equations so I can’t trust you. A calculator exists solely for the realm of mathematics, where you can afford to more or less throw away the value of human input and overall craftsmanship. That is not the case with something like this, which - while it leans in to engineering - is in effect viewed as a work of art by people who give a shit about the actual…

[dead]

Re: Open-source Zig book

#355

Post by dns_snek »

goku12 wrote: post #344
dns_snek wrote: post #282

Earlier quoted context omitted.

It's not that simple though, Zig has equivalent spatial memory safety which prevents issues that are pretty consistently among (or at) the top of the list for most dangerous vulnerability classes. And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the…

> And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the properties/invariants that you have to preserve. How do you make such boldly dismissive assertions if you don't have enough experience with Rust? You are talking as if these invariants are some…

> How do you make such boldly dismissive assertions

As I said that's my understanding from talking and listening to people who have a lot of experience with Rust, Zig, and C.

So generally speaking, are you saying that writing correct unsafe Rust is only as difficult as writing correct Zig code and not, as I understand it to be, significantly more difficult?

Re: Open-source Zig book

#356

Post by dns_snek »

ViewTrick1002 wrote: post #346
dns_snek wrote: post #282

Earlier quoted context omitted.

It's not that simple though, Zig has equivalent spatial memory safety which prevents issues that are pretty consistently among (or at) the top of the list for most dangerous vulnerability classes. And while I don't have enough experience with Rust to claim this first hand, my understanding is that writing correct unsafe Rust code is at least an order of magnitude harder than writing correct Zig code due to all of the…

I would compare the recent Rust Android post [1], where they have a 5000x lower memory vulnerability rate compared to traditional C/C++ with the number of segfaults found in Bun. [2] In my opinion Zig does not move the needle on real safety when the codebase becomes sufficiently complex. [1]: https://security.googleblog.com/2025/11/rust-in-android-move... [2]: https://github.com/oven-sh/bun/issues?q=segfault%20OR%20s…

Why are we comparing a number of exploitable vulnerabilities to the number of segfault reports? Where does the "5000x" figure come from?

Re: Open-source Zig book

#357

Post by ModernMech »

fransje26 wrote: post #299
latexr wrote: post #272

Earlier quoted context omitted.

> To call Rust syntax beautiful is a stretch. I don’t see where the comment you’re replying to does that (was it edited?). Their comment says nothing about aesthetics.

Higher up > Rust is the small, beautiful language hiding inside of Modern C++

That says Rust is beautiful, not its syntax.

Re: Open-source Zig book

#358

Post by ModernMech »

sgt wrote: post #307
pjmlp wrote: post #289

Earlier quoted context omitted.

If we ignore recent movents in govermental cybersecurity agencies, and big tech to move away from unsafe programming languages, as much as technically possible. Introducing a language with the same safety as Modula-2 or Object Pascal, would make sense in the 1990's, nowadays with improved type systems making the transition from academia into mainstream, we (the industry) know better. It is not only Rust, it is Linear…

Of those listed, I'd bet Swift (having had experience with it) is the most pleasant to work with. I just hope it takes off on the systems and backend side at some point.

Swift's main problem is that Apple is holding it back but also it'd be nothing without Apple's involvement.

Re: Open-source Zig book

#359

Post by ecshafer »

rudedogg wrote: post #281

I submitted this and unfortunately it is likely AI generated. The authors github history suggests it at the very least, along with seemingly misunderstanding a reference to a Zig language feature (labeled blocks - https://zig.guide/language-basics/labelled-blocks/ ) in the project issues ( https://github.com/zigbook/zigbook/issues/4 ). I’m not sure how much value is to be had here, and it’s unfortunate the author was…

That github exchange is hilarious and bizarre. It's very obviously people talking to not people.

Re: Open-source Zig book

#360

Post by MatthiasPortzel »

rudedogg wrote: post #281

I submitted this and unfortunately it is likely AI generated. The authors github history suggests it at the very least, along with seemingly misunderstanding a reference to a Zig language feature (labeled blocks - https://zig.guide/language-basics/labelled-blocks/ ) in the project issues ( https://github.com/zigbook/zigbook/issues/4 ). I’m not sure how much value is to be had here, and it’s unfortunate the author was…

I seem to remember seeing this a week or two ago, and it was very obviously AI generated. (For those unfamiliar with Zig, AI is awful at generating Zig code: small sample dataset and the language updates faster than the models.) Reading it today I had a hard time spotting issues. So I think the author put a fair amount of work into cleaning up hallucinations and fixing inaccuracies.
Post reply on HN