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

51–60 of 183 posts

Re: Zig and the design choices within

#51

Post by tialaramex »

rvrb wrote: post #29
brabel wrote: post #24

Earlier quoted context omitted.

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

It's not that subtle, the thing that we knew doesn't work still doesn't work.

Some of our problems are novelties because before Grace Hopper basically nobody is writing software so there aren't centuries of lessons in how to do it properly - but this problem isn't like that, all the safety critical industries could tell you that "professionalism" won't prevent the mistakes and what you need is mechanism so that the mistakes cannot happen.

Let me give you an example I like from the railways, which are about twice as old. One night, signaller comes on duty and during the day a team of engineers have been doing work on "his" signal box. Still, things seem to check out and he gets to work, a train approaches, he tries to give them their whole route but their next signal seems stuck and won't "pull off" from danger - he blames the engineers of course. In accordance with regulations the train's driver phones the signaller, signaller explains that he can't release the signal but gives the driver authoriation, per standard instructions, to pass only one signal and proceed at caution (ie slowly enough to stop short of any obstruction) to the next signal. The next signal though is the same, the signaller is annoyed, blames the engineers again, same order to proceed at caution. The next signal is the same again. But, just after the driver receives their authority and passes that signal the signaller gets another call. Funny, surely they haven't reached the next signal yet? No. They're face-to-face with another train. Some junction points ("switch" if you're American) have failed, the train has been sent into another, both stopped short and nobody is injured.

The points failure had been detected. If the signaller had carefully checked his instruments they'd have told him that this failure had occurred and that is why it wasn't clear to set those danger signals off which is why, try as hard as he could, they could not be pulled off. It is mechanically impossible, not because of professionalism, or capability or any other brave words but physically impossible to kill everybody by clearing the conflicting signals in this state.

Mechanism.

Re: Zig and the design choices within

#52

Post by NobodyNada »

kristoff_it wrote: post #17
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…

Some people like Zig because it makes it easier to learn how to program the machine sitting in front of them. It's better at that than Rust because it's less abstracted, and it's better at that than C because you don't have to worry all the toolchain nonsense / weird conventions / weak type system of the C ecosystem. As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly comp…

> As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick

A bit of a nitpick here: the trick is for creating a new vector of a different type, that reuses the allocation of an existing vector, using only safe code. "Resetting an arraylist/vector while reusing its memory" is just vec.clear() if you're not changing the type. And it's trivial to change the type of a vector with unsafe (the docs even have examples of this); the only advantage of the "trick" is to ensure you'll get a panic if you screw up the alignment of the types.

And after that blog post, the Rust team accepted a proposal to introduce a vec.recycle() function to change the type of a vector without needing that trick (and with compile-time checks for alignment compatibility): https://github.com/rust-lang/rust/pull/148416

But that example aside, I agree with your overall premise -- Zig and Rust share different design goals here, and Zig's lower level of abstraction makes it more approachable to learn than a language like Rust.

Re: Zig and the design choices within

#53

Post by pron »

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…

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work.

... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age.

The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requires less competence than other forms of thinking about a program, then why Rust? Why not ATS? After all, Rust does let you eliminate certain bugs at compile time, but ATS lets you eliminate so many more.

Re: Zig and the design choices within

#54

Post by cassepipe »

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…

A lot of people strive for something that is simple (not like Rust, and I am not only talking about the borrow checker) and explicit ("debug your program, not your knowledge of the language) but also doesn't bear the historical cruft and idiosyncrasies of C. The fact that it can integrate with C code means that if you are already using C you can adopt it incrementally, plus it works as a build system and cross-compiler and I believe a package manager too.

So to sum up : A powerful C without the quirks that manages to keep things simple but is also a batteries-included experience with a smooth adoption path. What's not to love ?

Re: Zig and the design choices within

#55

Post by fransje26 »

guywithahat wrote: post #33
deepriverfish wrote: post #30

It's interesting to see how popular Zig is becoming, I thought it would get overshadowed by Rust and it would go nowhere.

It's interesting how much Rust has slowed down. There is still some development in linux otherwise people seem to be over it. I think Rust just doesn't offer enough in terms of features, and is overshadowed by languages like Go or C++ in terms of what developers are really looking for. Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's…

> Rust's popularity seems to be dropping or holding steady in indexes like TIOBE

Oh, 14th [1]. That's a lot lower than I would have expected, based purely on the amount of noise surrounding Rust.

[1] https://www.tiobe.com/tiobe-index/

Re: Zig and the design choices within

#56

Post by eviks »

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…

> But I oppositely believe the world needs more tech that treats professionals as experts, not kids.

Which part of expertise is rejecting the fact that safety through professional mind tricks in lieu of better underlying language design is unattainable?

Re: Zig and the design choices within

#57

Post by whytevuhuni »

pron wrote: post #53
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…

>> Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. ... and the same could be said about Rust, only with Rust we can already see that it suffers from relatively low adoption at a relatively advanced age. The funny thing about that claim is that it leads to an obvious question: if working harder to satisfy the compiler is something that requ…

> Why not ATS?

As in, why not use a language with much stronger formal verification? Because people have tried it and failed.

Like you said, Rust is hard, it already feels at the limit of what people can handle.

But unlike ATS, many people have tried Rust and succeeded, and some Rust programmers even claim that they become very productive with it after a while. I very much doubt the same could be said about ATS.

Re: Zig and the design choices within

#58

Post by valcron1000 »

pron wrote: post #34

This treatment of memory safety is becoming almost a cargo cult at this point. If this were a binary issue, then clearly Rust wouldn't cut it because it is quite common in Rust (much more so than in, say, Java) to rely on unsafe code. So if you think Rust is good at memory safety, that means that you must believe that some level of unsafety is acceptable. The only question is how much, and what you're willing to pay…

> Zig must also be good for eliminating the same ones.

But Zig does not eliminate them, but rather it might catch them at runtime. The difference here is that Rust promises that it will detect them at compile time, long before I ship my code.

> The property of memory safety is itself not binary in both languages

In this case it is: either you catch the issue at compile time, or you don't. This is the same as type safety: just because Python can detect type errors at runtime it does not mean that it's as "type safe" as, for ex. Haskell. This might be due to imprecise usage of terms but that's just the way it's discussed in the craft.

Re: Zig and the design choices within

#59

Post by raincole »

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…

> for Ruby is ergonomics…

In other words, "I kinda enjoy it"?

Re: Zig and the design choices within

#60

Post by NobodyNada »

pron wrote: post #34

This treatment of memory safety is becoming almost a cargo cult at this point. If this were a binary issue, then clearly Rust wouldn't cut it because it is quite common in Rust (much more so than in, say, Java) to rely on unsafe code. So if you think Rust is good at memory safety, that means that you must believe that some level of unsafety is acceptable. The only question is how much, and what you're willing to pay…

Limiting to the "top 5" vulnerabilities by number of CVEs feels like cherry-picking. It's true that spatial memory safety is lower-hanging fruit than temporal memory safety, sure; but the CVE list is dominated by vulnerabilities in web applications which are mostly already written in fully memory-safe languages (additionally, these vulnerabilities are typically mitigated by library/API design rather than by programming language design, in which case Rust gives you quite a lot more tools than Zig for designing APIs that have concepts of unsanitized/untrusted data, but I digress). If you filter for vulnerabilities relevant to applications that would typically be written in C/C++/Rust/Zig, use-after-free is easily within the top 5.

The exact positioning within the top 10 is also quite noisy: if you look at last year's list, UAF is in the #1 spot for actively exploited vulnerabilities, even beating out all the web ones: https://cwe.mitre.org/top25/archive/2023/2023_kev_list.html

Lastly, filtering on CVEs has a high selection bias: just because security researchers go for the easy vulnerabilities first doesn't mean that the harder ones can be ignored. As high-profile projects adopt tooling and mitigations to reduce the impact of spatial memory safety problems, it's common to see a sudden increase in CVEs related to temporal memory safety. This is not because use-after-free bugs somehow became more common or severe -- it's because once you eliminate the easy source of vulnerabilities, the attackers shift their attention to the new lowest-hanging fruit.

Post reply on HN