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

Partially Matching Zig Enums

matklad.github.io

Post reply on HN
Print view View original

121–130 of 170 posts

Re: Partially Matching Zig Enums

#121

Post by Ygg2 »

lossolo wrote: post #105
Ygg2 wrote: post #99

Earlier quoted context omitted.

Yeah, it's not binary; it's just a step function. /s No, it's as close to binary as you can get. Is your only source of Undefined Behavior FFI specially marked functions and/or packages? Have you checked data races for violating thread safety invariants? If yes - You're safe. Allow a bit of unsafety into the system, like Go, and the unsafety can creep into your ecosystem. See https://www.ralfj.de/blog/2025/07/24/memo…

> Is Go in mostly safer than C++? Maybe Maybe? You forgot /s there? Asking if Go is mostly safer than C++ is like asking if child proof caps are mostly safer than mason jars for medicine. > https://www.ralfj.de/blog/2025/07/24/memory-safety.html Can you show RCE using this? Because, to this day, no one has been able to show me a reasonable program that someone would write and that would result in RCE from "Go memory…

> Maybe? You forgot /s there?

Neither are memory safe, so if you're going by the "safe in practice" definition then it has to be verified experimentally. Hence - maybe.

> Can you show RCE using this?

RCE and Undefined Behavior are two intersecting sets. Not all UB is RCE, but what all UBs are hard to track bugs that happen at most inconvenient times.

> You can’t prove Rust code "safe" in the absolute.

Sure you can't prove that any Turing machine has some property X or not. But Rust Belt (pdf https://hal.science/hal-01633165v2/document) is proof that safety of safe blocks is extensible and can apply to safe interfaces encapsulating unsafe well.

> We still hit unsoundness[1] and miscompiles in safe code (equal pointers comparing unequal... [2])

Your [1] is an LLVM bug.

As for [2] yeah there ARE bugs, wrong flags, bus they are fixing it and triggering most requires stuff like nightly, hitting bugs in specific hardware/LLVM, or very contrived trait constructions.

I mean sure by that token nothing is ever safe, reality is crooked, coins have three sides, and white is black, so traffic crossing are mass hallucinations.

> On the safety spectrum: C/C++ -> Zig -> Go -> Rust

Honestly it goes like this. C -> C++ --> Zig ------> Go --------------------------------------------------------------------------> Rust --> Ada Core

Re: Partially Matching Zig Enums

#122

Post by CyberDildonics »

pron wrote: post #119
CyberDildonics wrote: post #110

Earlier quoted context omitted.

We keep talking about completely different things. You said zig is safer than C++, then to make that argument you keep trying to redefine what safety means to include only features in the language syntax but not done in libraries while saying memory leaks don't matter and automatically freeing memory correctly doesn't matter.

I am not redefining what safety means. I am using the same definition of safety used in this entire thread by those debating the pros and cons of Rust being safer than Zig. I definitely didn't say that memory leaks don't matter. They could possibly matter more than memory safety. They are just not called memory safety bugs, or code injection bugs, or off-by-one bugs. Memory safety is a name given to a class of bugs t…

it's really hard to say which of them leads to the fewest memory leaks

Not the one with manual memory management.

Re: Partially Matching Zig Enums

#123

Post by tialaramex »

pron wrote: post #118
tialaramex wrote: post #117

Earlier quoted context omitted.

The same useless claim could be made for C and with the same effect. The trick Rust is doing here that Zig is not is that Rust's safe contracts are always what we would call wide contracts. As a safe Rust programmer it's never your fault because you were "holding it wrong". For example If you insist on sorting a Vec even though Foozles all claim they're greater even than themselves, Rust doesn't say (as C and C++ do)…

> The same useless claim could be made for C and with the same effect It really can't be. Memory safety is problematic because it's a common cause of some dangerous bugs . Of the two main kinds of memory safety, Rust generally eliminates both, leaving only unsafe Rust and foreign code as possible sites of memory unsafety. Zig, on the other hand, generally eliminates only the more dangerous kind, leaving only unsafe Z…

> It really can't be.

I just did it.

Re: Partially Matching Zig Enums

#124

Post by pron »

tialaramex wrote: post #123
pron wrote: post #118

Earlier quoted context omitted.

> The same useless claim could be made for C and with the same effect It really can't be. Memory safety is problematic because it's a common cause of some dangerous bugs . Of the two main kinds of memory safety, Rust generally eliminates both, leaving only unsafe Rust and foreign code as possible sites of memory unsafety. Zig, on the other hand, generally eliminates only the more dangerous kind, leaving only unsafe Z…

> It really can't be. I just did it.

Fair enough :)

I guess one could claim that some feature is useful because it eliminates certain classes of bugs while another is useless because it eliminates certain classes of bugs (which happens to be the more impactful subset of the former class), it's just not a very compelling claim, especially the way you presented it, which is:

Something bad happens, say an attacker steals my data. Rust is useful because I can eliminate spatial and temporal safety as the cause, leaving only all others, while in Zig I can eliminate spatial unsafety as the cause (leaving all others), but that's just as useless as C, where I can eliminate neither spatial nor temporal unsafety as the cause.

I can see how it may be reasonable to argue that all are equally useless, but given that spatial unsafety is the largest subclass of unsafety that causes security vulnerabilities, I'm not convinced by the argument that eliminating it is completely useless while eliminating a somewhat larger class (i.e. adding a smaller marginal benefit than the first step) becomes very useful.

Re: Partially Matching Zig Enums

#125

Post by uecker »

pron wrote: post #120
uecker wrote: post #115

Earlier quoted context omitted.

Memory safety - as now being popularized by Rust in its current form - mostly corresponds to not having UB in C or C++. My point is that this not the only definition and not even the definition Rust started with. Memory leaks are often a part of the definition of memory safety because otherwise it is trivial to fix use-after-free, i.e. simple never free the memory. Rust dropped this part because it was too hard. So i…

Well, when Rust came out I had only been programming in C and C++ for about 15, maybe 20 years, but I think that even then we generally used memory safety to refer to problems that can cause "type confusion". In any event, given that none of the languages mentioned here - C, C++, Zig, or Rust - prevent memory leaks, I don't think that the question of whether or not we include it under the umbrella of memory safety co…

I think it is relevant exactly because Rust exceptionalism is based on sloppy arguments that are fallacious because they narrow down topics and definitions in some invalid way, i.e. only considered memory safety while ignoring safety in general, only considering a specific definition of memory safety, only considering the safe subset of Rust, only accepting language-level safety, etc. until at the end it looks that Rust is extremely different to other languages while it is just some incremental step.

Re: Partially Matching Zig Enums

#126

Post by lossolo »

Ygg2 wrote: post #121
lossolo wrote: post #105

Earlier quoted context omitted.

> Is Go in mostly safer than C++? Maybe Maybe? You forgot /s there? Asking if Go is mostly safer than C++ is like asking if child proof caps are mostly safer than mason jars for medicine. > https://www.ralfj.de/blog/2025/07/24/memory-safety.html Can you show RCE using this? Because, to this day, no one has been able to show me a reasonable program that someone would write and that would result in RCE from "Go memory…

> Maybe? You forgot /s there? Neither are memory safe, so if you're going by the "safe in practice" definition then it has to be verified experimentally. Hence - maybe. > Can you show RCE using this? RCE and Undefined Behavior are two intersecting sets. Not all UB is RCE, but what all UBs are hard to track bugs that happen at most inconvenient times. > You can’t prove Rust code "safe" in the absolute. Sure you can't…

> Neither are memory safe, so if you're going by the "safe in practice" definition then it has to be verified experimentally. Hence - maybe.

This is a ridiculous claim that it’s only "maybe". It’s so obvious, it’s like saying cars are not safe to drive, but if you use seatbelts and have airbags, then MAYBE they’re safer. I have verified this experimentally, like millions of other people. This argument is totally in bad faith, given the sea of CVEs caused by memory safety issues in C++ versus the almost virtually non-existent problem in safe Go in practice.

> Your [1] is an LLVM bug.

Yes, unfixed for two years. I don’t have this bug in Go, for example, so why, as a Rust user, should I care whose fault it is? If you buy a car and the engine doesn’t work as it should in some cases, do you accept the manufacturer saying, "Well, that’s the engine manufacturer’s issue, so all is OK"?

> As for [2] yeah there ARE bugs, wrong flags, bus they are fixing it and triggering most requires stuff like nightly, hitting bugs in specific hardware/LLVM, or very contrived trait constructions.

That went fast from "proven to be safe" to "yeah there are bugs".

> Honestly it goes like this. C -> C++ --> Zig ------> Go --------------------------------------------------------------------------> Rust --> Ada Core

And how did you arrive at these numbers of "—"? Did you "verify them experimentally"? Because I claim otherwise:

C --> C++ ----> Zig --------------> Go ----> Rust --> Ada Core

can you prove me wrong or prove you are right? You can't. It seems we can only agree on the ranking of the languages.

Re: Partially Matching Zig Enums

#127

Post by CyberDildonics »

scrubs wrote: post #112
CyberDildonics wrote: post #89

Earlier quoted context omitted.

Zig has defer. And C has free, but you have to remember to use it and use it correctly every single time instead of the memory working by default with no intervention. Says most people in the field of software correctness Not true, the last 30 years have had much safer languages than before java, scripting languages, modern C++ and rust. That's true, but these are not memory safety guarantees. Pragmatically they mean…

>C has free; zig has defer But even in a c++ destructer if you forget to dealloc a private heap allocation ... then you're in the same darn place.

And if you divide by 0 your program still crashes. The reality is that you can use vectors for memory allocations and you never have to worry about it. If you do need to wrap resource allocation, you do it once, test it and it will probably work from then on. This is much better than the alternative of having to remember to free the memory, close the file, unlock the mutex correctly every single time you need one.

Re: Partially Matching Zig Enums

#128

Post by pron »

CyberDildonics wrote: post #122
pron wrote: post #119

Earlier quoted context omitted.

I am not redefining what safety means. I am using the same definition of safety used in this entire thread by those debating the pros and cons of Rust being safer than Zig. I definitely didn't say that memory leaks don't matter. They could possibly matter more than memory safety. They are just not called memory safety bugs, or code injection bugs, or off-by-one bugs. Memory safety is a name given to a class of bugs t…

it's really hard to say which of them leads to the fewest memory leaks Not the one with manual memory management.

I would say: not the ones with spooky implicit actions and hidden heap allocations, but we won't know until we actually have data.

When writing in a low-level language, I always want to know where I'm allocating and where I'm deallocating. Zig makes allocations easier to spot than in C/C++/Rust, and deallocations easier to spot than in C++/Rust. That's just how I like it. I'm not saying everyone must have the same preference.

Re: Partially Matching Zig Enums

#129

Post by pron »

uecker wrote: post #125
pron wrote: post #120

Earlier quoted context omitted.

Well, when Rust came out I had only been programming in C and C++ for about 15, maybe 20 years, but I think that even then we generally used memory safety to refer to problems that can cause "type confusion". In any event, given that none of the languages mentioned here - C, C++, Zig, or Rust - prevent memory leaks, I don't think that the question of whether or not we include it under the umbrella of memory safety co…

I think it is relevant exactly because Rust exceptionalism is based on sloppy arguments that are fallacious because they narrow down topics and definitions in some invalid way, i.e. only considered memory safety while ignoring safety in general, only considering a specific definition of memory safety, only considering the safe subset of Rust, only accepting language-level safety, etc. until at the end it looks that R…

I completely agree, but given that even in Java, which eliminates the memory leaks Rust doesn't, programs still have bugs and security vulnerabilities, I don't think it's about what is and isn't memory safety. Most of the software that runs the world has been written in memory-safe languages for a very long time. It's more about understanding the significance and role of memory safety. With that comes the insight that it isn't binary and, while important (out-of-bounds access in C and C++ is, as far as we know empirically, one of the leading causes of security vulnerabilities), eliminating it has both a finite benefit and a cost that need to be considered.

Re: Partially Matching Zig Enums

#130

Post by pron »

CyberDildonics wrote: post #127
scrubs wrote: post #112

Earlier quoted context omitted.

>C has free; zig has defer But even in a c++ destructer if you forget to dealloc a private heap allocation ... then you're in the same darn place.

And if you divide by 0 your program still crashes. The reality is that you can use vectors for memory allocations and you never have to worry about it. If you do need to wrap resource allocation, you do it once, test it and it will probably work from then on. This is much better than the alternative of having to remember to free the memory, close the file, unlock the mutex correctly every single time you need one.

I don't agree that "you never have to worry about it" unless you're also using smart pointers, which is rarely what I want.

I think that the alternative where all allocations and deallocations are made clear (in Zig, allocating routines are "coloured" by convention) is the better alternative, at least for the kind of low-level programming I do and for my way of thinking about low-level code.

When I write code where I don't want to see or worry about each implementation detail or see exactly where and when each operation is executed, I use Java.

Post reply on HN