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

How safe is Zig?

scattered-thoughts.net

Post reply on HN
Print view View original

141–150 of 259 posts

Re: How safe is Zig?

#141

Post by LAC-Tech »

Safe enough. You can use `std.testing.allocator` and it will report leaks etc in your test cases.

What rust does sounds like a good idea in theory. In practice it rejects too many valid programs, over-complicates the language, and makes me feel like a circus animal being trained to jump through hoops. Zigs solution is hands down better for actually getting work done, plus it's so dead simple to use arena allocation and fixed buffers that you're likely allocating a lot less in the first place.

Rust tries to make allocation implicit, leaving you confused when it detects an error. Zig makes memory management explicit but gives you amazing tools to deal with it - I have a much clearer mental model in my head of what goes on.

Full disclaimer, I'm pretty bad at systems programming. Zig is the only one I've used where I didn't feel like memory management was a massive headache.

Re: How safe is Zig?

#142

Post by cogman10 »

the__alchemist wrote: post #135
avgcorrection wrote: post #118

A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…

This is a concise summary of why I'm betting on Rust as the future of performant and embedded computing. You or I could poke holes in it for quite some time. Yet, I imagine the holes would be smaller and less numerous than in any other language capable in these domains. I think some of the push back is from domains where Rust isn't uniquely suited. Eg, You see a lot of complexity in Rust for server backends; eg async…

> I think some of the push back is from domains where Rust isn't uniquely suited. Eg, You see a lot of complexity in Rust for server backends; eg async and traits. So, someone not used to Rust may see these, and assume Rust is overly complex. In these domains, there are alternatives that can stand toe-to-toe with it. In lower-level domains, it's not clear there are.

The big win for rust in these domains is startup time, memory usage, and distributable size.

It may be that these things outweigh the easier programming of go or java.

Now if you have a big long running server with lots of hardware at your disposal then rust doesn't make a whole lot of sense. However, if want something like an aws lambda or rapid up/down scaling based on load, rust might start to look a lot more tempting.

Re: How safe is Zig?

#143

Post by Arnavion »

ArrayBoundCheck wrote: post #132
XelNika wrote: post #129

Earlier quoted context omitted.

With Zig and Rust you have to explicitly opt-out with `ReleaseFast` and `unsafe` respectively, that makes a big difference. Rust has the added safety that you cannot (to my knowledge at least) gain performance by opting out with a flag at compile-time, it has to be done with optimized `unsafe` blocks directly in the code. Lazy C++ is unsafe, lazy Zig is safe-ish, lazy Rust is safe. Given how lazy most programmers are…

[dead]

>It has nothing to do with opting out.

It does. The original code compiled because the borrow is computed using `unsafe`. That `unsafe` is the opt-out.

>Zig, Rust and no language saves you when you write incorrect unsafe code. My original point is disqualifying c tools is misleading and everything suffers from incorrect unsafe code

And the other people's point is that if one language defaults to writing unsafe code and the other language requires opting out of safety to write unsafe code, then the second language has merit over the first.

Re: How safe is Zig?

#144

Post by kristoff_it »

avgcorrection wrote: post #125
kristoff_it wrote: post #122

Earlier quoted context omitted.

> Of course Rust does the same thing with certain non-memory-safety bug checks like integer overflow. The problem with getting lost too much in the ironclad certainties of Rust is that you start forgetting that simplicity ( papa pia ) protects you from other problems. You can get certain programs in pretty messed up states with an unwanted wrap around. Programming is hard. Rust is cool, very cool, but it's not a univ…

Nothing Is Perfect is a common refrain and non-argument. If option A has 20 defects and option B has the superset of 25 defects then option A is better—the fact that option A has defects at all is completely besides the point with regards to relative measurements.

Zig keeps overflow checks in the main release mode (ReleaseSafe), Rust defines ints as naturally wrapping in release. This means that Rust is not a strict superset of Zig in terms of safety, if you want to go down that route.

I personally am not interested at all in abstract discussions about sets of errors. Reality is much more complicated, each error needs to be evaluated with regards to the probability of causing it and the associated cost. Both things vary wildly depending on the project at hand.

Re: How safe is Zig?

#145

Post by raphlinus »

_vvhw wrote: post #88
raphlinus wrote: post #74

Earlier quoted context omitted.

I am skeptical until I see the details, and strongly suspect you are dealing with a "safe-ish" language rather than one which has Rust-level guarantees. Uninitialized memory reads are undefined behavior in basically all memory models in the C tradition. In Rust it is not possible to make a reference to a slice containing uninitialized memory without unsafe (and the rules around this have tightened relatively recently…

Hackers exploit any avenue (and usually come in through the basement!), regardless of how skeptical we might be that they won't. They don't need the details, they'll figure it out. You give them a scrap and they'll get the rest. It's a different way of thinking that we're not used to, and don't understand unless we're exposed to it first-hand, e.g. through red-teaming. For example, another way to think of this is tha…

Thanks for the explanation. I would consider that type of logic error more or less impossible to defend at the language level, but I can see how analysis tools can be helpful.

Re: How safe is Zig?

#146

Post by avgcorrection »

kristoff_it wrote: post #144
avgcorrection wrote: post #125

Earlier quoted context omitted.

Nothing Is Perfect is a common refrain and non-argument. If option A has 20 defects and option B has the superset of 25 defects then option A is better—the fact that option A has defects at all is completely besides the point with regards to relative measurements.

Zig keeps overflow checks in the main release mode (ReleaseSafe), Rust defines ints as naturally wrapping in release. This means that Rust is not a strict superset of Zig in terms of safety, if you want to go down that route. I personally am not interested at all in abstract discussions about sets of errors. Reality is much more complicated, each error needs to be evaluated with regards to the probability of causing…

> This means that Rust is not a strict superset of Zig in terms of safety, if you want to go down that route.

Fair.

> I personally am not interested at all in abstract discussions about sets of errors.

Abstract? Handwaving “no silver bullet” is even more abstract (non-specific).

Re: How safe is Zig?

#147

Post by Klonoar »

LAC-Tech wrote: post #141

Safe enough. You can use `std.testing.allocator` and it will report leaks etc in your test cases. What rust does sounds like a good idea in theory. In practice it rejects too many valid programs, over-complicates the language, and makes me feel like a circus animal being trained to jump through hoops. Zigs solution is hands down better for actually getting work done, plus it's so dead simple to use arena allocation a…

>Zigs solution is hands down better for actually getting work done

Rust has seen significant usage in large companies; they wouldn't be using it unless it was usable for "real work".

>Full disclaimer, I'm pretty bad at systems programming. Zig is the only one I've used where I didn't feel like memory management was a massive headache.

I'd say this about Rust, though. Rust's mental model is very straightforward if you accept the borrow-checker and stop fighting it. Can you list any examples of what you think is a headache...?

>In practice it rejects too many valid programs, over-complicates the language, and makes me feel like a circus animal being trained to jump through hoops.

I've found that jumping through those hoops leads to things running in production that don't make me get up in the middle of the night. Can you show me a "valid program" that Rust rejects?

Re: How safe is Zig?

#148

Post by lmm »

ajross wrote: post #62
klyrs wrote: post #54

Earlier quoted context omitted.

As a Zig fan, I disagree. I think it's really important to examine the toolchain that beginners are going to use. > I'm also focusing on software as it is typically shipped, ignoring eg bounds checking compilers like tcc or quarantining allocators like hardened_malloc which are rarely used because of the performance overhead. To advertize that Zig is perfectly safe because things like ASan exist would be misleading,…

> To advertize that Zig is perfectly safe because things like ASan exist would be misleading Exactly! And for the same reason. You frame your comparison within the bounds of techniques that are used in practice. You don't refuse to compare a tool ahead of time, especially when doing so reinforces your priors. To be blunt: ASan is great. ASan finds bugs. Everyone should use ASan. Everyone should advocate for ASan. But…

> You frame your comparison within the bounds of techniques that are used in practice.

Well, is ASan used in practice, by the relevant target audience (i.e. mainstream C++ developers)? My guess is that the vast majority of the people both Rust and Zig are aiming for are people who don't use ASan with C++ today and wouldn't use ASan with Rust or Zig if they switched to them.

Re: How safe is Zig?

#149

Post by lmm »

uecker wrote: post #52
hyperpape wrote: post #10

Earlier quoted context omitted.

Can you explain why, in spite of the fact that (according to you) C & C++ aren't that unsafe, critical projects like Chromium can't get this right? https://twitter.com/pcwalton/status/1539112080590217217 Is the Project Zero team just too lazy to remind Chromium to use sanitizers?

I think the big question is, whether two teams writing software on a fixed budget using Rust or C using modern tools and best practices would end up with a safer product. I think this is not clear at all.

I think it's very clear for anything other than a no-true-Scotsman definition of "modern tools and best practices" (which is sadly the only one that seems to exist).

Re: How safe is Zig?

#150

Post by Klonoar »

avgcorrection wrote: post #118

A meta point to make here but I don’t quite understand the pushback that Rust has gotten. How often does a language come around that flat out eliminates certain errors statically, and at the same time manages to stay in that low-level-capable pocket? And doesn’t require a PhD (or heck, a scholarly stipend) to use? Honestly that might be a once in a lifetime kind of thing. But not requiring a PhD (hyperbole) is not en…

>A meta point to make here but I don’t quite understand the pushback that Rust has gotten.

The non-CS "human" answer to this is that so much of tech and programming is unfortunately tied to identity. There are developers who view their choices as bordering on religion (from editors to languages to operating systems and so on) and across the entire industry you can see where some will take the slightest hint that things could be better as an affront to their identity.

The more that Rust grows and winds up in the industry, the more this will continue to happen.

Post reply on HN