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

301–310 of 426 posts

Re: Open-source Zig book

#301

Post by cryptocod3 »

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 irrelevant stdlib and compiler implementation details.

Re: Open-source Zig book

#302

Post by IshKebab »

vlovich123 wrote: post #258
IshKebab wrote: post #239

Earlier quoted context omitted.

I guess comptime is a little different but yeah I wouldn't say it fundamentally changes how you think about software. I wouldn't say that about OCaml either really though. It's not wildly different in the way that e.g. Lean's type system, or Rust's borrow checker or Haskell's purity is.

D has similar comptime capabilities if I recall correctly and proceeds Zig by almost 2 decades or so.

I don't think it's the same. You can do template metaprogramming, but Zig lets you use Zig itself which is a lot nicer.

I'm not a D programmer though so I could be wrong.

Re: Open-source Zig book

#304

Post by UpsideDownRide »

Wowfunhappy wrote: post #297
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…

Are you sure? Right on https://www.zigbook.net/chapters/00__zigbook_introduction it says: > The Zigbook intentionally contains no AI-generated content—it is hand-written, carefully curated, and continuously updated to reflect the latest language features and best practices. The author could of course be lying. But why would you use AI and then very explicitly call out that you’re not using AI?

Because AI content is at minimum controversial nowadays. And if you are ok with lying about authorship then It is not further down the pole to embelish the lie a bit more

Re: Open-source Zig book

#305

Post by zwnow »

59nadir wrote: post #300
zwnow wrote: post #206

Earlier quoted context omitted.

I'd also throw Erlang/Elixir out there. And I really wished Elm wasn't such a trainwreck of a project...

No need to include Elixir here; none of the important bits that will change how you view software come from Elixir, it's just a skin on top of Erlang (+ some standard library wrappers) and that's it.

I'd argue more people use Elixir over Erlang at this point. Sure its just an abstraction on top of Erlang, but people learn through Elixir nowadays, not through Erlang.

Re: Open-source Zig book

#306

Post by fuzztester »

userbinator wrote: post #197
poly2it wrote: post #195

> Learning Zig is not just about adding a language to your resume. It is about fundamentally changing how you think about software. I'm not sure what they expect, but to me Zig looks very much like C with a modern standard lib and slightly different syntax. This isn't groundbreaking, not a thought paradigm which should be that novel to most system engineers like for example OCaml could be. Stuff like this alienates p…

For those who actually want to learn languages which are "fundamentally changing how you think about software", I'd recommend the Lisp family and APL family.

And Forth.

And 6502 assembly. ;)

And SNOBOL.

And Icon.

And ...

Re: Open-source Zig book

#307

Post by sgt »

pjmlp wrote: post #289
sgt wrote: post #268

Earlier quoted context omitted.

Sure but there's this belief in the Rust community that it's not responsible anymore to write software that isn't memory safe on the same level as Rust. So Zig would fail that, but then you could also consider C++ unsuitable for production software - and we know it clearly is still suitable. I predict Zig will just become more and more popular (and with better, although not as complete- memory safety), and be applied…

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.

Re: Open-source Zig book

#308

Post by rudedogg »

Wowfunhappy wrote: post #297
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…

Are you sure? Right on https://www.zigbook.net/chapters/00__zigbook_introduction it says: > The Zigbook intentionally contains no AI-generated content—it is hand-written, carefully curated, and continuously updated to reflect the latest language features and best practices. The author could of course be lying. But why would you use AI and then very explicitly call out that you’re not using AI?

> Are you sure?

There are too many things off about the origin and author to not be suspicious of it. I’m not sure what the motivation was, but it seems likely. I do think they used the Zig source code heavily, and put together a pipeline of some sort feeding relevant context into the LLM, or maybe just codex or w/e instructed to read in the source.

It seems like it had to take quite a bit of effort to make, and is interesting on its own. And I would trust it more if I knew how it was made (LLMs or not).

As another suspicious data point see this issue by the author: https://github.com/microsoft/vscode/issues/272725

Edit: https://news.ycombinator.com/item?id=45952581 found some concrete issues

Re: Open-source Zig book

#309

Post by PaulRobinson »

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'd love it if we can stop the "Oh, this might be AI, so it's probably crap" thing that has taken over HN recently.

1. There is no evidence this is AI generated. The author claims it wasn't, and on the specific issue you cite, he explains why he's struggling with understanding it, even if the answer is "obvious" to most people here.

2. Even if it were AI generated, that does not automatically make it worthless. In fact, this looks pretty decent as a resource. Producing learning material is one of the few areas we can likely be confident that AI can add value, if the tools are used carefully - it's a lot better at that than producing working software, because synthesising knowledge seen elsewhere and moving it into a new relatable paradigm (which is what LLMs do, and excel at), is the job of teaching.

3. If it's maintained or not is neither here nor there - can it provide value to somebody right now, today? If yes, it's worth sharing today. It might not be in 6 months.

4. If there are hallucinations, we'll figure them out and prove the claim it is AI generated one way or another, and decide the overall value. If there is one hallucination per paragraph, it's a problem. If it's one every 5 chapters, it might be, but probably isn't. If it's one in 62 chapters, it's beating the error rate of human writers quite some way.

Yes, the GitHub history looks "off", but maybe they didn't want to develop in public and just wanted to get a clean v1.0 out there. Maybe it was all AI generated and they're hiding. I'm not sure it matters, to be honest.

But I do find it grating that every time somebody even suspects an LLM was involved, there is a rush of upvotes for "calling it out". This isn't rational thinking. It's not using data to make decisions, its not logical to assume all LLM-assisted writing is slop (even if some of it is), and it's actually not helpful in this case to somebody who is keen to learn zig to decide if this resource is useful or not: there are many programming tutorials written by human experts that are utterly useless, this might be a lot better.

Re: Open-source Zig book

#310

Post by krapp »

booleandilemma wrote: post #303

I wonder if HN should mandate an [AI] tag for links to AI generated content.

It should be against HN policy to link to AI generated content just as it's against HN policy to post AI generated comments.

Futile as it is.

Post reply on HN