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

361–370 of 426 posts

Re: Open-source Zig book

#361

Post by ninetyninenine »

jasode wrote: post #248
ninetyninenine wrote: post #214

Earlier quoted context omitted.

>Rust is that for C++ No it's not. Rust has roots in functional languages. It is completely orthoganol to C++.

Graydon Hoare, a former C++ programmer on Mozilla Firefox and the original creator of Rust, acknowledges that for many people, Rust has become a viable alternative to C++ : https://graydon2.dreamwidth.org/307291.html And on slide #4, he mentions that "C++ is well past expiration date" : https://venge.net/graydon/talks/intro-talk-2.pdf It's possible that Graydon's earliest private versions of Rust the 4 years prior to…

So?

Zig, D, and C are also alternatives to C++. It’s a class of languages that have zero cost abstractions.

Rust is NOT a beautiful language hiding inside of C++. It is not an evolution of C++. I’m pointing out that what you said is objectively wrong.

Can rust replace C++ as a programming language that has a fast performance profile due to zero cost abstractions? Yes. In the same way that Haskell can replace Python, yes it can.

Re: Open-source Zig book

#362

Post by diego_moita »

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)

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

Agree. What matters is quality, regardless of what/who made it.

O.t.o.h., it is funny to see tech people here, that work on implementing technology, taking an approach so... Luddite and "anti-tech".

Re: Open-source Zig book

#363

Post by nvlled »

ViewTrick1002 wrote: post #339
sgt wrote: post #257

Earlier quoted context omitted.

> and isn't suitable for any of the domains where Rust excels. That's a pretty bold claim since Zig is specifically designed for systems programming, low level stuff, network services, databases (think Tigerbeetle). It's not memory safe like Rust is, but it comes with constructs that make it simple to build largely memory safe programs.

Given the density of memory issues in the Bun issue tracker I have a hard time squaring the statement that Zig makes it "easy" to build memory safe programs. https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

> https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

It should be noted that most of those issues are created by opening a link that bun creates when it crashes, they are not yet reviewed/confirmed and most likely a lot of them are dulplicates of the same issue.

Re: Open-source Zig book

#364

Post by ViewTrick1002 »

dns_snek wrote: post #356
ViewTrick1002 wrote: post #346

Earlier quoted context omitted.

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?

The number is memory vulnerabilities. Not if they are exploitable. The numbers comes from this part of the article:

    This near-miss inevitably raises the question: "If Rust can have memory safety vulnerabilities, then what’s the point?"

    The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).

    Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.
https://security.googleblog.com/2025/11/rust-in-android-move...

Re: Open-source Zig book

#365

Post by jasonjmcghee »

CraftingLinks wrote: post #331
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 looked into that project issue your referencing. There is absolutely zero mentioning of zig labeled blocks in that exchange. There is no misunderstanding or confusion whatsoever.

It's a formatting bug with zig labeled blocks and the response was a screenshot of code without one, saying (paraphrasing) lgtm it must be on your end.

See the first screenshot in the exchange with newlines breaking up the label and block - and maybe this for proper formatting https://zig.guide/language-basics/labelled-blocks/

Re: Open-source Zig book

#366

Post by ViewTrick1002 »

nvlled wrote: post #363
ViewTrick1002 wrote: post #339

Earlier quoted context omitted.

Given the density of memory issues in the Bun issue tracker I have a hard time squaring the statement that Zig makes it "easy" to build memory safe programs. https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm...

> https://github.com/oven-sh/bun/issues?q=segfault%20OR%20segm... It should be noted that most of those issues are created by opening a link that bun creates when it crashes, they are not yet reviewed/confirmed and most likely a lot of them are dulplicates of the same issue.

Comparing Deno most of their segfaults come from having to integrate with V8, and their density is a fraction compared to Bun.

Re: Open-source Zig book

#367

Post by frakt0x90 »

bool3max wrote: post #313
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…

We really are in the trenches. How is this garbage #1 on the front page of *HN* right now? Even if it was totally legitimate, the "landing page" (its design) and the headline ("Learning Zig is not just about adding a language to your resume. It is about fundamentally changing how you think about software."?????) should discredit it immediately.

I imagine a lot of people didn't even click. They see free Zig materials and upvote.

Re: Open-source Zig book

#368

Post by eibrahim »

diego_moita wrote: post #362
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)

> 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. Agree. What matters is quality, regardless of what/who made it. O.t.o.h., it is funny to see tech people here, that work on implementing technology, taking an approach so... Luddite and "anti-tech".

I agree man. I love the HN community but it seems a lot more cynical than usual :).

i think 90% of the comments were about the AI part rather than the actual product - which seems very cool and definitely took a lot of effort to put together.

Re: Open-source Zig book

#369

Post by dilap »

sgt wrote: post #228
dilap wrote: post #126

Earlier quoted context omitted.

I read the first few paragraphs. Very much reads like LLM slop to me... E.g., "Zig takes a different path. It reveals complexity—and then gives you the tools to master it." If we had a reliable oracle, I would happily bet a $K on significant LLM authorship.

Yeah and then why would they explicitly deny it? Maybe the AI was instructed not to reveal its origin. It's painful to enjoy this book if I know it's likely made by an LLM.

If you find it useful no harm in enjoying it! The main problem with AI content is it's just not good enough...yet. It'll get there. The LLMs just need more real-world feedback incorporated, rather than being the ultimate has-read-everything,-actually-knows-nothing dweeb (a lot of humans are like this too). (You can see the first signs of overcoming this w/ latest models coding skills, which are stronger via RL, I believe.) (Not first hand knowledge tho -- pot kettle black situation there.)

Re: Open-source Zig book

#370

Post by pelasaco »

oscargrouch wrote: post #343
pelasaco wrote: post #249

I'm a C/C++ developer. I write production code in MQL5 (C-like) and Go, and I use Python for research and Automation. I can work with other languages as well, but I keep asking myself: why should I learn Zig? If I want to do system or network programming, my current stack already covers those needs — and adding Rust would probably make it even more future-proof. But Zig? This is a genuine question, because the "Zig b…

My take on this as someone that professionally coded in C, C++, Go, Rust, Python (and former darlings of the past) is that Zig gives you the sort of control that C does with enough niceties as to not break into other idioms like C++ and Rust does in terms of complexity. Rust "breaks" on some low level stuff when you need to deal with unsafe (another idiom) or when you need to rely on proc-macros to have a component s…

thank you for your detailed answer. I found another great discussion around Zig here https://news.ycombinator.com/item?id=26374647
Post reply on HN