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

121–130 of 259 posts

Re: How safe is Zig?

#121

Post by ghusbands »

raphlinus wrote: post #74
_vvhw wrote: post #64

Earlier quoted context omitted.

I worked on a static analysis tool to detect bleeds in outgoing email attachments, looking for non-zero padding in the ZIP file format. It caught different banking/investment systems written in memory safe languages leaking server RAM. You could sometimes see the whole intranet web page, that the teller or broker used to generate and send the statement, leaking through. Bleeds terrify me, no matter the language. The…

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…

I would imagine that the scenario is simply reuse of some buffer without clearing it, maybe in an attempt to save on allocations. It can happen across so many (even safe) languages. It doesn't matter what guarantees you have around uninitialised memory if you're reusing an initialised buffer yourself.

Re: How safe is Zig?

#122

Post by kristoff_it »

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…

> 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 universal silver bullet.

Re: How safe is Zig?

#123

Post by avgcorrection »

lmh wrote: post #34

Question for Zig experts: Is it possible, in principle, to use comptime to obtain Rust-like safety? If this was a library, could it be extended to provide even stronger guarantees at compile time, as in a dependent type system used for formal verification? Of course, this does not preclude a similar approach in Rust or C++ or other languages; but comptime's simplicity and generality seem like they might be beneficial…

Why would the mere existence of some static-eval capability give you that affordance?

Researchers have been working on these three things for decades. Yes, “comptime” isn’t some Zig invention but a somewhat limited (and anachronistic to a degree) version of what researchers have added to research versions of ML and Ocaml. So can it implement all the static language goodies of Rust and give you dependent types? Sure, why not? After all, computer scientists never had the idea that you can evaluate values and types at compile-time. Now all those research papers about static programming language design will wither on their roots now that people can just use the simplicity and generality of `comptime` to prove programs correct.

Re: How safe is Zig?

#124

Post by anonymoushn »

dkersten wrote: post #47

I’m not sure I understand the value of an allocator that doesn’t reuse allocations, as a bug prevention thing. Is it just for performance? (Since its never reused, allocation can simply be incrementing an offset by the size of the allocation)? Because beyond that, you can get the same benefit in C by simply never calling free on the memory you want to “protect” against use-after-free.

The allocations are freed and the addresses are never reused. So heap use-after-frees are segfaults.

Re: How safe is Zig?

#125

Post by avgcorrection »

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

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

Re: How safe is Zig?

#126

Post by infamouscow »

_vvhw wrote: post #42
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…

This is almost what we do for TigerBeetle, a new distributed database being written in Zig. All memory is statically allocated at startup [1]. Thereafter, there are zero calls to malloc() or free(). We run a single-threaded control plane for a simple concurrency model, and because we use io_uring—multithreaded I/O is less of a necessary evil than it used to be. I find that the design is more memory efficient because…

> Latency is predictable and gloriously smooth, and the system overall is much simpler and fun to program.

This has also been my experience building a database in Zig. It's such a joy.

Re: How safe is Zig?

#127

Post by Karrot_Kream »

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.

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 forever. Should we use static types which make it slower to iterate or dynamic types that help converge on error-free behavior with less programmer intervention? The tradeoffs have become clearer over the years but the decision remains as nuanced as ever. And as the decision space remains nuanced, I'm excited about languages exploring other areas of the design space like Zig or Nim.

Re: How safe is Zig?

#128

Post by anonymoushn »

KerrAvon wrote: post #77
AlotOfReading wrote: post #43

Earlier quoted context omitted.

I think we basically agree. Hypothetically ideal memory safety is strictly better, but sanitizers are better than nothing for code using fundamentally unsafe languages. My personal experience is that more people are dissuaded from sanitizer usage more by hypothetical (and manageable) issues like overhead than real implementation problems.

If you can afford a 10-50% across-the-board performance reduction, why would you not use a higher-level, actually safe language like Ruby or Python? Remember that the context of this article is Zig vs other languages, so the assumption is you’re writing new code.

For Ruby or Python I think you'll be paying more than 90%

Re: How safe is Zig?

#129

Post by XelNika »

ArrayBoundCheck wrote: post #105
hyperpape wrote: post #95

Earlier quoted context omitted.

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.

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, I consider that a strong argument against C++.

Re: How safe is Zig?

#130

Post by remexre »

AndyKelley wrote: post #81

I have one trick up my sleeve for memory safety of locals. I'm looking forward to experimenting with it during an upcoming release cycle of Zig. However, this release cycle (0.10.0) is all about polishing the self-hosted compiler and shipping it. I'll be sure to make a blog post about it exploring the tradeoffs - it won't be a silver bullet - and I'm sure it will be a lively discussion. The idea is (1) escape analysi…

Could this be integrated into the LLVM SafeStack pass? (I don't know how related Zig still is to LLVM, or if your thing would be implemented there.)
Post reply on HN