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

Zig and the design choices within

blueberrywren.dev

Post reply on HN
Print view View original

21–30 of 183 posts

Re: Zig and the design choices within

#21

Post by kiitos »

jasperry wrote: post #20
kiitos wrote: post #5

probably should define memory safety before using it as an evaluation criterion otherwise, not sure who the audience of this piece is supposed to be, but it's written in a pretty combative tone, which will not be persuasive to anyone who isn't already persuaded, so i guess more of a rant than anything worth sharing here

Someone could know what memory safety is and still be persuaded (or reminded) by an argument that it's not okay to adopt a non-memory-safe language due to all the security issues. The author did cite evidence from the Chromium project, which to me elevates it above a mere rant.

my point with memory safety is that it is not a single well defined concept

so if you wanna talk about it you at least gotta say which definition you're using

Re: Zig and the design choices within

#22

Post by Joker_vD »

> Zig does not have a way to iterate through a slice or similar in any way except one-at-a-time forwards. Anything else? You're using a while loop, and you'll enjoy it.

    INCR[U] i FROM 0 TO len(arr) [BY 1] DO ...

    DECR[U] i FROM len(arr) TO 0 [BY 1] DO ...
Although actual BLISS-77 had inclusive semantics for the upper bounds in both forms. Which, on one hand, allows you to write

    DECRU i FROM UINT_MAX TO 0 DO ...
and expect it to Just Work™ (hopefully? No idea if it worked on actual implementation ― but would've been nice, writing the same in e.g. C is kinda annoying; good luck with Golang pre-1.22 and even then, getting that one last iteration is quirky) but on the other hand, inclusive upper bounds require you to write add that "-1" almost everywhere.

Re: Zig and the design choices within

#23

Post by pron »

taylorallred wrote: post #13

I have admired many parts of Zig and its philosophy but I've never seen it as a language that I want to use. What I've noticed is that Zig users care most about explicitness, simplicity, and minimal indirection. This leads to a lot of syntax that is cumbersome to read (albeit unambiguous) like casting and a lack of "convenience" features. I can't help but think that maybe they're right and that this philosophy probab…

Design choices that are appropriate for low-level programming may be less appropriate for high-level programming and vice versa. In low level programming, you may want to see "on the page" anything that could translate to some machine work, because in low-level programming, such details may be essential to the algorithm. In high-level programming, the same details are likely not essential to the algorithm, and so you don't want to see them.

Re: Zig and the design choices within

#24

Post by brabel »

ivanjermakov wrote: post #15

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawba…

> Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids.

That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten.

But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And those mistakes can have catastrophic consequences. Professionals should go for tools that help them prevent those mistakes, right??

Re: Zig and the design choices within

#25

Post by brabel »

Joker_vD wrote: post #22

> Zig does not have a way to iterate through a slice or similar in any way except one-at-a-time forwards. Anything else? You're using a while loop, and you'll enjoy it. INCR[U] i FROM 0 TO len(arr) [BY 1] DO ... DECR[U] i FROM len(arr) TO 0 [BY 1] DO ... Although actual BLISS-77 had inclusive semantics for the upper bounds in both forms. Which, on one hand, allows you to write DECRU i FROM UINT_MAX TO 0 DO ... and ex…

That looks a lot like Common Lisp LOOP macro!

Re: Zig and the design choices within

#26

Post by ModernMech »

brabel wrote: post #24
ivanjermakov wrote: post #15

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawba…

> Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids. That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten. But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And tho…

> But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent.

That's true but it's deeper than that -- no matter how much time goes by, there will always be people new to the language, and they will always make newbie mistakes if the language allows them to. So "just be an expert and don't write shoddy code" doesn't scale, no matter how hard you personally try.

Re: Zig and the design choices within

#27

Post by Joker_vD »

brabel wrote: post #25
Joker_vD wrote: post #22

> Zig does not have a way to iterate through a slice or similar in any way except one-at-a-time forwards. Anything else? You're using a while loop, and you'll enjoy it. INCR[U] i FROM 0 TO len(arr) [BY 1] DO ... DECR[U] i FROM len(arr) TO 0 [BY 1] DO ... Although actual BLISS-77 had inclusive semantics for the upper bounds in both forms. Which, on one hand, allows you to write DECRU i FROM UINT_MAX TO 0 DO ... and ex…

That looks a lot like Common Lisp LOOP macro!

Honestly, that's been the standard form of FOR loops since Fortran and Algol-60 until C decided to spice things up.

Re: Zig and the design choices within

#28

Post by pron »

torben-friis wrote: post #4

This article works really well to illustrate a question I have: why is Zig so popular in posts here? For most languages I can usually see one or two “killer features” that push the language: For Rust is taking C space with memory safety + modern semantics, for Go is being easy to learn by most engineers + parallelization, for Ruby is ergonomics… I don’t see any similar pitch for zig other than a general “I kinda enjo…

Turns out that "killer features" are frequently not killer enough. You mentioned Rust with its memory-safety killer-feature, and yet Rust is quite old now (about as old as Java was when JDK 6 came out or JS was when jQuery came out) and its adoption rate is low for such an old age.

I have no idea if Zig will be successful or not, but even if you look just at memory safety, I think it does a better job at that than Rust. If you look at MITRE's top 25 dangerous weaknesses [1] or top 10 exploited weaknesses [2], you'll see that Rust spends almost all of its complexity on eliminating weaknesses that don't even make the top 5 on either list, while Zig's more limited memory safety addresses the more dangerous memory-safety-related problems without paying so dearly to solve less severe issues.

Now, I personally think that Zig's combination of expressivity and simplicity, while still being low-level, is an unprecedented killer feature (I wrote more about it here: https://news.ycombinator.com/item?id=45852774) which makes the language design quite revolutionary and fascinating. This could perhaps translate to correctness benefits.

[1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html

[2]: https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html

Re: Zig and the design choices within

#29

Post by rvrb »

brabel wrote: post #24
ivanjermakov wrote: post #15

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawba…

> Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids. That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten. But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And tho…

Zig is a tool that helps professionals prevent those mistakes.

"Memory safe languages" are tools that prevent professionals from making those mistakes.

It's a subtle but important difference. Zig attempts to leave some humanity to the developer.

When someone says they are incapable of earning or deserving that, I feel sad.

Post reply on HN