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

161–170 of 170 posts

Re: Partially Matching Zig Enums

#161

Post by hitekker »

Ygg2 wrote: post #99
hudon wrote: post #73

Earlier quoted context omitted.

I interpreted his post as saying it's not binary safe/unsafe, but rather a spectrum, with Java safer than C because of particular features that have pros and cons, not because of a magic free safe/unsafe switch. He's advocating for more nuance, not less.

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…

^ This comment demonstrates what I meant by "thick lattice of ideology"

Re: Partially Matching Zig Enums

#162

Post by akkad33 »

pron wrote: post #71
tialaramex wrote: post #56

Earlier quoted context omitted.

> There is simply no justification to make that equivalence. I explained in some detail exactly why this equivalence exists. I actually have a small hope that this time there are enough people who think it's a bad idea that we don't have to watch this play out for decades before the realisation as we did with C and C++. Yes it's exactly Rice's Theorem, it's that simple and that drastic. You can choose what to do when…

> I explained in some detail exactly why this equivalence exists. No, you assumed that Zig and C++ are equivalent and concluded that they'll follow a similar trajectory. It's your premise that's unjustified. A problem you'd have to contend with is that Rust is much more similar to C++ than Zig in multiple respects, which may matter more or less than the level of safety when predicting the language trajectory. > But y…

> No, you assumed that Zig and C++ are equivalent and concluded that they'll follow a similar trajectory. It's your premise that's unjustified.

They did not say Zig and C++ are equivalent

Re: Partially Matching Zig Enums

#163

Post by CyberDildonics »

pron wrote: post #160
CyberDildonics wrote: post #155

Earlier quoted context omitted.

You can do whatever you want, but systemically it is a lot better than doing it manually and anyone experienced with modern C++ will tell you it essentially stops being a problem. Also you say not preventing memory leaks but your only example is cycles, which is only happens with reference counting, which is only even necessary with multi-threading. Also it implies a data structure that contains a bunch of shared poi…

> You can do whatever you want, but systemically it is a lot better than doing it manually and anyone experienced with modern C++ will tell you it essentially stops being a problem. Yeah, it's fine, but I think that systematically the Zig approach is a lot better for my needs and preferences. > In practice this doesn't really happen. I've only been programming low-level code for 25 years or so, including hard realtim…

You know when destructors run, they run at the end of a scope. It's very clear. Have you used modern C++?

Re: Partially Matching Zig Enums

#164

Post by pron »

CyberDildonics wrote: post #163
pron wrote: post #160

Earlier quoted context omitted.

> You can do whatever you want, but systemically it is a lot better than doing it manually and anyone experienced with modern C++ will tell you it essentially stops being a problem. Yeah, it's fine, but I think that systematically the Zig approach is a lot better for my needs and preferences. > In practice this doesn't really happen. I've only been programming low-level code for 25 years or so, including hard realtim…

You know when destructors run, they run at the end of a scope. It's very clear. Have you used modern C++?

Destructors are not modern C++. When I learnt C++, circa 1993, we had destructors. Saying, you should just remember to always look up which destructors run sounds as convincing to me as how I must sound to you when I say you should just remember to put a defer statement when you need to free a resource.

In my low-level code I don't want any calls that I can't see as explicit calls in the code (BTW, it's not that I don't use destructors at all - I'm not a fanatic - it's that I try to avoid relying on RAII).

Re: Partially Matching Zig Enums

#165

Post by drjeats »

SleepyMyroslav wrote: post #139
drjeats wrote: post #137

Earlier quoted context omitted.

> Then why do my data structures detect if I go out of bounds? Because you have iterator debugging and/or assertions turned on and are only using non-primitive data structures (e.g. std::vector, std::array). Zig does the thing that Rust and Go do where it makes the primary primitive for pointers to chunks of memory (slices) bounds checked. You can opt out with optimization settings, but I think most programs will bui…

>I think most programs will build in "safe release" mode Do you have any citations to support this 'safe release' theory? Like there are not many Zig applications and not many of them document their decisions. One i could find [1] does not mention safe anywhere. 1. https://ghostty.org/docs/install/build

Ghostty is trying to be a speed demon terminal, so I'd expect it to use ReleaseFast.

The current build system docs don't prioritize one build mode over another:

https://ziglang.org/learn/build-system/

> Standard optimization options allow the person running zig build to select between Debug, ReleaseSafe, ReleaseFast, and ReleaseSmall. By default none of the release options are considered the preferable choice by the build script, and the user must make a decision in order to create a release build.

But for more opinionated recommendations, ReleaseSafe is clearly favored:

https://zig.news/kristoff/how-to-release-your-zig-applicatio...

> ReleaseSafe should be considered the main mode to be used for releases: it applies optimizations but still maintains certain safety checks (eg overflow and array out of bound) that are absolutely worth the overhead when releasing software that deals with tricky sources of input (eg, the internet).

https://zighelp.org/chapter-3/

> Users are recommended to develop their software with runtime safety enabled, despite its small speed disadvantage.

If you could somehow collect real-world data, the overwhelming majority of Zig programs aren't released and have likely only made debug builds :P

Re: Partially Matching Zig Enums

#166

Post by CyberDildonics »

pron wrote: post #164
CyberDildonics wrote: post #163

Earlier quoted context omitted.

You know when destructors run, they run at the end of a scope. It's very clear. Have you used modern C++?

Destructors are not modern C++. When I learnt C++, circa 1993, we had destructors. Saying, you should just remember to always look up which destructors run sounds as convincing to me as how I must sound to you when I say you should just remember to put a defer statement when you need to free a resource. In my low-level code I don't want any calls that I can't see as explicit calls in the code (BTW, it's not that I do…

No one said they were and that isn't the point (and you didn't answer the question). When destructors run isn't a mystery it's deterministic and you know resources need to be freed so you know what it is going to do.

Hidden functions aren't a big deal in practice. You have functions calling other functions in C all the time and you have to know what they are doing under the hood, same with data structures and their operators.

Re: Partially Matching Zig Enums

#167

Post by pron »

CyberDildonics wrote: post #166
pron wrote: post #164

Earlier quoted context omitted.

Destructors are not modern C++. When I learnt C++, circa 1993, we had destructors. Saying, you should just remember to always look up which destructors run sounds as convincing to me as how I must sound to you when I say you should just remember to put a defer statement when you need to free a resource. In my low-level code I don't want any calls that I can't see as explicit calls in the code (BTW, it's not that I do…

No one said they were and that isn't the point (and you didn't answer the question). When destructors run isn't a mystery it's deterministic and you know resources need to be freed so you know what it is going to do. Hidden functions aren't a big deal in practice. You have functions calling other functions in C all the time and you have to know what they are doing under the hood, same with data structures and their o…

> Hidden functions aren't a big deal in practice.

Again, that's like me saying "forgetting defer isn't a big deal in practice." You seem to disagree with that and I disagree with your assertion. It's largely a matter of personal preference.

And no, except for some compile-time tests/assertions and a smattering of lambdas, we don't use most of "modern C++" (or almost any of std). Sometimes we need to emit hand-crafted machine code, and sometimes we may need to mess around with stack frames directly (which means we can't use destructors in those cases. We do use destructors a fair bit, but I personally soured on RAII some ten years ago.

Re: Partially Matching Zig Enums

#168

Post by CyberDildonics »

pron wrote: post #167
CyberDildonics wrote: post #166

Earlier quoted context omitted.

No one said they were and that isn't the point (and you didn't answer the question). When destructors run isn't a mystery it's deterministic and you know resources need to be freed so you know what it is going to do. Hidden functions aren't a big deal in practice. You have functions calling other functions in C all the time and you have to know what they are doing under the hood, same with data structures and their o…

> Hidden functions aren't a big deal in practice. Again, that's like me saying "forgetting defer isn't a big deal in practice." You seem to disagree with that and I disagree with your assertion. It's largely a matter of personal preference. And no, except for some compile-time tests/assertions and a smattering of lambdas, we don't use most of "modern C++" (or almost any of std). Sometimes we need to emit hand-crafted…

Again, that's like me saying "forgetting defer isn't a big deal in practice."

It's the opposite, because for defer you need to be proactive and do it every time, but destructors are going to do the right thing and work, but if you question what's happening you can investigate.

One is happening automatically and already works, the other is manual and you always have to remember or your program is broken.

we don't use most of "modern C++"

You might want to try it out, it would probably help with all these misunderstandings.

Re: Partially Matching Zig Enums

#169

Post by ViewTrick1002 »

pron wrote: post #159
ViewTrick1002 wrote: post #157

Earlier quoted context omitted.

Which as long as no new functionality is added keeps getting safer. https://security.googleblog.com/2024/09/eliminating-memory-s...

I thought there's no such thing as "safer". There's only whatever guarantees Rust happens to make that can prevent almost 1% of the bugs a language like ATS can prevent, which is safe, and anything that doesn't make those exact same guarantees, which is unsafe and completely worthless. Anyway, you help prove my point, which is that even those who claim to believe in a binary distinction between what Rust happens to g…

And quite evidently the design and community for both C and C++ leads to design with massive amounts of very high severity bugs.

Of course ignoring how Rust also helps against logic bugs by managing null values and having an expressive type system.

You seem to be the one completely focused on the binary question since that is the only thing that allows C , C++ etc. to still be part of the conversation.

Re: Partially Matching Zig Enums

#170

Post by pron »

CyberDildonics wrote: post #168
pron wrote: post #167

Earlier quoted context omitted.

> Hidden functions aren't a big deal in practice. Again, that's like me saying "forgetting defer isn't a big deal in practice." You seem to disagree with that and I disagree with your assertion. It's largely a matter of personal preference. And no, except for some compile-time tests/assertions and a smattering of lambdas, we don't use most of "modern C++" (or almost any of std). Sometimes we need to emit hand-crafted…

Again, that's like me saying "forgetting defer isn't a big deal in practice." It's the opposite, because for defer you need to be proactive and do it every time, but destructors are going to do the right thing and work, but if you question what's happening you can investigate. One is happening automatically and already works, the other is manual and you always have to remember or your program is broken. we don't use…

> It's the opposite, because for defer you need to be proactive and do it every time, but destructors are going to do the right thing and work

No, it's the opposite, because with defer you always see all the operations that are happening, while with destructors you have to be proactive and every time check what operations are done in your methods.

Look, I've used destructors a lot for many, many years (and still do, as it's not always up to me), they have pros and cons, some people really like them, some don't, and it's okay. It's not like there's some universal truth here or empirical data that strongly favours one side over the other.

> You might want to try it out, it would probably help with all these misunderstandings.

Thank you for your suggestion, but being one of the most foundational pieces of C++ software in the world, I think we've got it covered.

Post reply on HN