[flagged]
Open-source Zig book
411–420 of 426 posts
Re: Open-source Zig book
#412Oh no, it's paginated
Re: Open-source Zig book
#413Earlier quoted context omitted.
Created https://github.com/zigbook/zigbook/issues/18
Aaaand it's gone!
> 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.
From the readme.
Re: Open-source Zig book
#414I 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 issue has been deleted. In addition, the author has tagged other issues with labels that are not appropriate for the mission of being a core zig learning resource:
https://github.com/zigbook/zigbook/issues/25
"AI ALLEGATION" and "RE**ED COMPLAINT"
Re: Open-source Zig book
#415I 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 issue has been deleted. In addition, the author has tagged other issues with labels that are not appropriate for the mission of being a core zig learning resource: https://github.com/zigbook/zigbook/issues/25 "AI ALLEGATION" and "RE**ED COMPLAINT"
'zigbook' also seems to be using other accounts as sock puppets: 'zigglang' and 'zig-vm'
Re: Open-source Zig book
#416Earlier quoted context omitted.
> 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…
I wasn’t clear then. I would rather have N language features of increasing complexity/UX issues for dealing with increasingly complex situations rather than one mechanism to rule them all that can fail to instantiate in all cases (of whatever complexity). That’s the tradeoff that I want.
Why? Because that leads to better ergonomics for me, in my experience. When library authors can polish the interface with the least powerful mechanism with the best guarantees, I can use it, misuse it, and get decent error messages.
What I want out of partial evaluation is just the boring 90’s technology of generalized “constant folding”.[1] I in principle don’t care if it is used to implement other things... as long as I don’t have surprising instantiation problems when using library code that perhaps the library author did not anticipate.
[1]: And Rust’s “const” approach is probably too limited at this stage. For my tastes. But the fallout of generalizing is not my problem so who am I to judge.
> Okay, and I don't want any problem of any kind in my language, but unfortunately, there are tradeoffs in programming language design.
I see.
> 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,
In my experience Rust being complicated is more of a problem for rustc contributors than it is for me.
> and still have some of those features exhibit the same problem.
Which you only use when you need them.
(I of course indirectly use macros since the standard library is full of them. At least those are nice enough to use. But I might have gotten some weird expansions before, though?)
That will have to do until there comes along a language where you can write anything interesting as library code and still expose a nice to use interface.
Re: Open-source Zig book
#417Earlier quoted context omitted.
Early talks by Andrew explicitly leaned into the notion that "software can be perfect", which is a deviation from how most programmers view software development. Zig also encourages you to "think like a computer" (also an explicit goal stated by Andrew) even more than C does on modern machines, given things like real vectors instead of relying on auto vectorization, the lack of a standard global allocator, and the la…
Has it changed how you program in other languages? Because that to me is the true mark of a thought-shifting language.
The big thing I would say I actually learned and would intentionally apply to other languages is SIMD programming. Otherwise, I'd say it gave me a much clearer mental model of memory management that helps me understand other languages much more fundamentally. Along with getting my hands directly on custom allocators for the first time, a question that took me time to figure out but gave me a lot of clarity in answering was "why can't you do closures in Zig?" Programming in Zig feels very Go-like, and not having closures was actually one of the biggest hiccups for me. I don't think this really changed how I write in other languages, but definitely how I think about other languages.
Re: Open-source Zig book
#418Earlier quoted context omitted.
> 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…
I wasn’t clear then. I would rather have N language features of increasing complexity/UX issues for dealing with increasingly complex situations rather than one mechanism to rule them all that can fail to instantiate in all cases (of whatever complexity). That’s the tradeoff that I want. Why? Because that leads to better ergonomics for me, in my experience. When library authors can polish the interface with the least…
> I would rather have N language features of increasing complexity/UX issues for dealing with increasingly complex situations rather than one mechanism to rule them all that can fail to instantiate in all cases (of whatever complexity). That’s the tradeoff that I want.
It's not that that single mechanism can fail in all situations. It's very unlikely to fail to compile in situations where the complicated language always compiles, and more likely to fail to compile when used for more complicated things, where macros may fail to compile, too.
It's probability of compilation failure is about the same as that of C++ templates [1]. Yeah, I've seen compilation bugs in templates, but I don't think that's on any C++ programmer's top ten problem list (and those bugs are usually when you start doing stranger things). Given that there can be runtime failures, which are far more dangerous than compilation failures and cannot be prevented, that the much less problematic compilation failures cannot always be prevented is a pretty small deal.
But okay, we all prefer different tradeoffs. That's why different languages choose design philosophies that appeal to different people.
[1]: It's basically a generalisation of the same idea, only with better error messages and much simpler code.
Re: Open-source Zig book
#419Earlier quoted context omitted.
Early talks by Andrew explicitly leaned into the notion that "software can be perfect", which is a deviation from how most programmers view software development. Zig also encourages you to "think like a computer" (also an explicit goal stated by Andrew) even more than C does on modern machines, given things like real vectors instead of relying on auto vectorization, the lack of a standard global allocator, and the la…
I'm not sure how what you stated is different from writing highly performance C.
Consider the following Zig:
const a = @Vector(4, i32){ 1, 2, 3, 4 };
const b = @Vector(4, i32){ 5, 6, 7, 8 };
const c = a + b;
vmovdqa xmm0, xmmword ptr [rip + .LCPI5_0]
vmovdqa xmmword ptr [rbp - 48], xmm0
vmovdqa xmm0, xmmword ptr [rip + .LCPI5_1]
vmovdqa xmmword ptr [rbp - 32], xmm0
vmovdqa xmm0, xmmword ptr [rip + .LCPI5_2]
vmovdqa xmmword ptr [rbp - 16], xmm0
Regarding the lack of a standard global allocator, and the lack of implicit buffering on standard io functions, these are simply features of the Zig standard library which are true of computers (computers do not have a standard global allocator nor do they implicitly buffer IO) but are not features of the C standard library, and therefore are not encouraged to use custom allocators or explicit buffering.
Re: Open-source Zig book
#420Earlier quoted context omitted.
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.
Fair. I'm not a compiler developer, so I'll defer to your expertise on that front.
That being said, I suppose my ultimate wonder is how small a Zig implementation could possibly be, if code size and implementation simplicity was the priority. In other words, could a hypothetical version of the Zig language have existed in the 80's or 90's, or was such a language simply out of reach of the computers of the time.