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

391–400 of 426 posts

Re: Open-source Zig book

#391

Post by 59nadir »

fuzztester wrote: post #385
59nadir wrote: post #323

Earlier quoted context omitted.

If you want to learn the actual mind changing aspects of the BEAM, clearly learning the simpler, smaller language with a more direct route to the juice is the way to go. Hence Erlang, not Elixir. I learned Elixir first back in 2015, and then learned Erlang, and have had the pleasure of using both in production. When all was said and done I really think Erlang was better, especially over a long enough time frame. As a…

>actual mind changing aspects of the BEAM What are those aspects? newb to this area.

A few key things:

- Leaning on a pre-emptive scheduler to maintain order even in the presence of ridiculous amounts of threads ("processes" on the BEAM) running

- Using supervision trees to specify how and when processes and their dependents should be restarted

- Using `gen_server` processes as a standard template for how a thread should be running

There's more to mine from using the BEAM, but I think the above are some of the most important aspects. The first two I've never found to be fully replicated anywhere other than in OTP/BEAM. You don't need them, but once you're bought into the BEAM they're incredibly nice to have.

Re: Open-source Zig book

#392

Post by keybored »

PaulRobinson wrote: post #319
toinewx wrote: post #317

Earlier quoted context omitted.

> 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. There is, actually, You may copy the introduction to Pangram and it will say 100% AI generated.

That's not evidence, at least not evidence that would stand up to a peer review if the author were to refute it.

What’s the evidence that it is human-generated? Oh I see. If it is AI generated then you still have to judge it by its merit, manually. (Or can I get an AI to do it for me?) And if they lied about it being human-authored? Well what if the author refutes that accusation? (Maybe using AI? But why judge them if they use AI to refute the claim? After all we must judge its on its own merit (repeats forever))

Re: Open-source Zig book

#393

Post by nabbed »

ecshafer wrote: post #359
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.

The exchange on https://github.com/zigbook/zigbook/issues/4? If so, your botdar is better than mine. While the project owner doesn't understand the issue at first, they seem to get it in the end. The exchange looks sort of normal to me, but then I guess I am doomed to be fooled regularly in our new regime.

Some text in the book itself is odd, but I'll be a guinea pig and try to learn zig from this book and see how far I get.

Re: Open-source Zig book

#394

Post by keybored »

pron wrote: post #332
obviouslynotme wrote: post #210

Earlier quoted context omitted.

There is nothing new under the Sun. However, some languages manifest as good rewrites of older languages. Rust is that for C++. Zig is that for C. Rust is the small, beautiful language hiding inside of Modern C++. Ownership isn't new. It's the core tenet of RAII. Rust just pulls it out of the backwards-compatible kitchen sink and builds it into the type system. Rust is worth learning just so that you can fully experi…

I think that describing Zig as a "rewrite of C" (good or otherwise) is as helpful as describing Python as a rewrite of Fortran. Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection. That makes the similarities to…

> Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection.

To my understanding (and I still haven’t used Zig) the “comptime” inherently (for sufficiently complex cases) leads to library code that needs to be actively tested for potential client use since the instantiation might fail. Which is not the case for the strict subset of “compile time” functionality that Java generics and whatnot bring.

I don’t want that in any “the new X” language. Maybe for experimental languages. But not for Rust or Zig or any other that tries to improve on the mainstream (of whatever nice) status quo.

Re: Open-source Zig book

#395

Post by keybored »

rjzzleep wrote: post #237
simonask wrote: post #232

Earlier quoted context omitted.

I don't know man, Rust's borrowing semantics are pretty new under the sun, and actually do change the way you think about software. It's a pretty momentous paradigm shift. Zig is nice too, but it's not that.

To call Rust syntax beautiful is a stretch. It seems that way in the beginning but then quickly devolves into a monstrosity when you start doing more complex things. Zig on the other specifically addresses syntax shortcomings in part of C. And it does it well. That claim of rust making C more safe because it’s more readable applies to Zig more than it does to Rust. I feel like the reason the rust zealots lobby like c…

> I feel like

Needless flame bait follows.

Re: Open-source Zig book

#396

Post by johnfn »

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 made a comment about it obviously being AI generated, and my comment[1] was quickly downvoted, and there were comments explaining how I was obviously incorrect ("Clearly your perception of what is AI generated is wrong."). My comment was pushed under many comments saying the book was a fantastic resource. Extremely strange.

https://news.ycombinator.com/item?id=45948608

Re: Open-source Zig book

#397

Post by MatthiasPortzel »

MatthiasPortzel wrote: post #360
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.

I checked my search history and I was thinking of a different website (zig toolbox, not linking intentionally, because it's purely AI slop).

Re: Open-source Zig book

#398

Post by pron »

LexiMax wrote: post #387
pron wrote: post #332

Earlier quoted context omitted.

I think that describing Zig as a "rewrite of C" (good or otherwise) is as helpful as describing Python as a rewrite of Fortran. Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection. That makes the similarities to…

To me, the fact that Zig has spent so long in development disqualifies it as being a "rewrite of C." To be clear, I really like Zig. But C is also a relatively simple language to both understand and implement because it doesn't have many features, and the features it does have aren't overly clever. Zig is a pretty easy language to learn, but the presence of comptime ratchets up the implementation difficulty significa…

I don't think it's the implementation that's delaying Zig's stabilisation, but the design. I'm also not sure comptime makes the implementation all that complicated. Lisp macros are more powerful than comptime (comptime is weaker by design) and they don't make Lisp implementation complicated.

Re: Open-source Zig book

#399

Post by pron »

keybored wrote: post #394
pron wrote: post #332

Earlier quoted context omitted.

I think that describing Zig as a "rewrite of C" (good or otherwise) is as helpful as describing Python as a rewrite of Fortran. Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection. That makes the similarities to…

> Zig does share some things with C - the language is simple and values explicitness - but at its core is one of the most sophisticated (and novel) programming primitives we've ever seen: A general and flexible partial evaluation engine with access to reflection. To my understanding (and I still haven’t used Zig) the “comptime” inherently (for sufficiently complex cases) leads to library code that needs to be activel…

> leads to library code that needs to be actively tested for potential client use since the instantiation might fail

True, like templates in C++ or macros in C or Rust. Although the code is "tested" at compile time, so at worst your compilation will fail.

> I don’t want that in any “the new X” language

Okay, and I don't want any problem of any kind in my language, but unfortunately, there are tradeoffs in programming language design. So the question is what you're getting in exchange for this problem. The answer is that you're getting a language that's both small and easy to inspect and understand. So you can pick having other problems in exchange for not having this one, but you can't pick no problems at all. In fact, you'll often get some variant of this very problem.

In Java, you can get by with high-level abstractions because we have a JIT, but performance in languages that are compiled AOT is more complicated. So, in addition to generics, low-level languages have other features that are not needed in Java. C++ has templates, which are a little more general than generics, but they can fail to instantiate, too. It also has preprocessor macros that can fail to compile in a client program. Rust has ordinary generics, which are checked once, but since that's not enough for a low-level language, it also has macros, and those can also fail to expand correctly.

So in practice, you either have one feature that can fail to compile in the client, or you can have the functionality split among multiple features, resulting in a more complicated language, and still have some of those features exhibit the same problem.

Re: Open-source Zig book

#400

Post by ecshafer »

nabbed wrote: post #393
ecshafer wrote: post #359

Earlier quoted context omitted.

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

The exchange on https://github.com/zigbook/zigbook/issues/4 ? If so, your botdar is better than mine. While the project owner doesn't understand the issue at first, they seem to get it in the end. The exchange looks sort of normal to me, but then I guess I am doomed to be fooled regularly in our new regime. Some text in the book itself is odd, but I'll be a guinea pig and try to learn zig from this book and see how f…

The exchanges look totally like a robot to me. It looks to be deleted now. But the first response that responded to the bug report with how many systems its tested on seems weird and robot like. Then the screenshot that the "person" has to be told to scroll down, that is very ai like.
Post reply on HN