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

131–140 of 259 posts

Re: How safe is Zig?

#131

Post by infamouscow »

pcwalton wrote: post #67
verdagon wrote: post #17

A lot of embedded devices and safety critical software sometimes don't even use a heap, and instead use pre-allocated chunks of memory whose size is calculated beforehand. It's memory safe, and has much more deterministic execution time. This is also a popular approach in games, especially ones with entity-component-system architectures. I'm excited about Zig for these use cases especially, it can be a much easier ap…

Even in this environment, you can still have dangling pointers to freed stack frames. There's no way around having a proper lifetime system, or a GC, if you want memory safety.

> Even in this environment, you can still have dangling pointers to freed stack frames.

How frequently does this happen in real software? I learned not to return pointers to stack allocated variables when I was 12 years old.

> There's no way around having a proper lifetime system, or a GC, if you want memory safety.

If you're building an HTTP caching program where you know the expiration times of objects, a Rust-style borrow-checker or garbage collector is not helping anyone.

Re: How safe is Zig?

#132

Post by ArrayBoundCheck »

XelNika wrote: post #129
ArrayBoundCheck wrote: post #105

Earlier quoted context omitted.

You missed the point. Just like the author did when he disqualified all the C++ tools Writing unsafe code and removing tools "because production" gets you unsafe code as shown in that rust cve

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]

Re: How safe is Zig?

#133

Post by messe »

kristoff_it wrote: post #114
skullt wrote: post #108

Earlier quoted context omitted.

Does that not contradict the Zig principle of no hidden allocations?

I don't know the precise details of what Andrew has in mind but the compiler can know how much memory is required for this kind of operation at compile time. This is different from normal heap allocation where you only know how much memory is needed at the last minute. At least in simple cases, this means that the memory for escaped variables could be allocated all at once at the beginning of the program not too diff…

Static allocation at the beginning of the program like that can only work for single threaded programs with non-recursive functions though, right?

I’d hazard a guess that the implementation will rely on use-after-free faulting, meaning that the use of any escaped variable will fault rather than corrupting the stack.

Re: How safe is Zig?

#134

Post by avgcorrection »

Karrot_Kream wrote: post #127
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.

But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior? You can't take this in isolation. The cognitive load of Rust takes a lot of defects out of the picture completely, but going off the beaten path in Rust takes a lot of design and patience. People have been fighting this fight fo…

> But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior?

Yes. If you change the entire premise of my example then things are indeed different.

Rust eliminates some defects entirely. Most other low-level languages do not. You would have to use a language like ATS to even compete.

That’s where the five-less-defects thing comes from.

Go down to ten effects? What are you talking about?

Re: How safe is Zig?

#135

Post by the__alchemist »

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

Re: How safe is Zig?

#136

Post by alfiedotwtf »

hyperpape wrote: post #95
ArrayBoundCheck wrote: post #87

Earlier quoted context omitted.

Considering how much I got downvoted no I don't want to comment more about this. But I'll let you ponder why while using rust has you could get a use after free sometimes https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4572...

Here's the commit: https://github.com/jeromefroe/lru-rs/pull/121/commits/416a2d... . I don't think this does much for your initial claim. Take the most generous reading you can--Rust isn't any better at preventing UAF than C/C++. That doesn't make safe C/C++ a thing, it means that Rust isn't an appropriate solution.

> Rust isn't any better at preventing UAF than C/C++

Maybe I'm missing something here?

Re: How safe is Zig?

#137

Post by Arnavion »

infamouscow wrote: post #131
pcwalton wrote: post #67

Earlier quoted context omitted.

Even in this environment, you can still have dangling pointers to freed stack frames. There's no way around having a proper lifetime system, or a GC, if you want memory safety.

> Even in this environment, you can still have dangling pointers to freed stack frames. How frequently does this happen in real software? I learned not to return pointers to stack allocated variables when I was 12 years old. > There's no way around having a proper lifetime system, or a GC, if you want memory safety. If you're building an HTTP caching program where you know the expiration times of objects, a Rust-styl…

>I learned not to return pointers to stack allocated variables when I was 12 years old.

So, if you slip while walking today, does that mean you didn't learn to walk when you were one year old?

Re: How safe is Zig?

#138

Post by dilap »

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…

What Rust does is incredibly cool and impressive.

But as someone that's dabbled a bit in both Zig and Rust, I think there's a lot of incidental complexity in Rust.

For example, despite having used them and read the docs, I'm still not exactly sure how namespaces work in Rust. It takes 30s to understand exactly what is going on in Zig.

Re: How safe is Zig?

#139

Post by tialaramex »

verdagon wrote: post #69
olig15 wrote: post #63

Earlier quoted context omitted.

But if you have a structure that contains offsets into another buffer somewhere, or an index, whatever - the wrong value here could be just as bad as a use-after-free. I don’t see how this is any safer. If you use memory after free from a malloc, with any chance you’ll hit a page fault, and your app will crash. If you have a index/pointer to another structure, you could still end up reading past the end of that struc…

That's just a logic error, and not memory unsafety which might risk UB or vulnerabilities. The type system enforces that if we use-after-"free" (remember, we're not free'ing or malloc'ing), we just get a different instance of the same type, which is memory-safe. You do bring up a valid broader concern. Ironically, this is a reason that GC'd systems can sometimes be better for privacy than Ada or Rust which uses a lot…

But, Java has exactly the same behaviour, the typical List in Java is ArrayList which sure enough has an indexed get() method.

There seems to be no practical difference here. Rust can do a reference to UserAccount, and Java can do an index into an ArrayList of UserAccounts. Or vice versa. As you wish.

Re: How safe is Zig?

#140

Post by coldtea »

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.

>If option A has 20 defects and option B has the superset of 25 defects then option A is better

Only if "defect count" is what you care for.

What if you don't give a fuck about defect count, but prefer simplicity to explore/experiment quickly, ease of use, time to market, and so on?

Post reply on HN