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

151–160 of 170 posts

Re: Partially Matching Zig Enums

#151

Post by CyberDildonics »

pron wrote: post #149
CyberDildonics wrote: post #146

Earlier quoted context omitted.

Oooh yeah, sorry no, smart pointers and destructors do prevent memory leaks. You said no then didn't back it up with anything and just went on a tangent of your own personal preferences.

`smart pointers + destructors => no memory leaks` does not entail `no memory leaks => smart pointers + destructors`. "My solution offers X, therefore, if you want X, you should use my solution" is just a logical fallacy; the conclusion doesn't follow from the premise. Also, I'm not so sure smart pointers and destructors actually prevent memory leaks. E.g. cycles. You can deal with cycles, but memory leaks due to them…

Also, I'm not so sure smart pointers and destructors actually prevent memory leaks

Well, they do, that's why people use them. I'm not sure why you would make the case against using another language that makes management manual.

Also reference counting cycles are only even possible if you use reference counting in the first place, which isn't necessary for single threaded scope based memory management.

Java does prevent leaks due to cycles

Fantastic but you said zig is safe than C++, what does java have to do with it?

Re: Partially Matching Zig Enums

#152

Post by CyberDildonics »

pron wrote: post #150
CyberDildonics wrote: post #147

Earlier quoted context omitted.

I didn't say it was safer https://news.ycombinator.com/item?id=44846507 Zig is safer than C++ I copy and pasted what you said.

> I copy and pasted what you said. No, you didn't. You wrote "You might like making and freeing every heap allocation but that doesn't mean it's safer." That is a very different claim (and one I didn't make) than "Zig is safer than C++". Zig is safer than C++ because it makes some absolute guarantees that C++ doesn't, and C++ doesn't make any absolute guarantees that Zig doesn't. But no memory leaks is not a guarante…

> I copy and pasted what you said.

No, you didn't.

I literally did. I linked your comment and copy pasted from it. What are you even talking about here? That's what you wrote, it's right there.

Re: Partially Matching Zig Enums

#153

Post by pron »

CyberDildonics wrote: post #151
pron wrote: post #149

Earlier quoted context omitted.

`smart pointers + destructors => no memory leaks` does not entail `no memory leaks => smart pointers + destructors`. "My solution offers X, therefore, if you want X, you should use my solution" is just a logical fallacy; the conclusion doesn't follow from the premise. Also, I'm not so sure smart pointers and destructors actually prevent memory leaks. E.g. cycles. You can deal with cycles, but memory leaks due to them…

Also, I'm not so sure smart pointers and destructors actually prevent memory leaks Well, they do, that's why people use them. I'm not sure why you would make the case against using another language that makes management manual. Also reference counting cycles are only even possible if you use reference counting in the first place, which isn't necessary for single threaded scope based memory management. Java does preve…

> Well, they do, that's why people use them.

They're one of the ways of reducing, not preventing memory leaks. And they're pretty ok at that, but I find other approaches to work better for me.

Re: Partially Matching Zig Enums

#154

Post by tialaramex »

pron wrote: post #148
tialaramex wrote: post #142

Earlier quoted context omitted.

Have you noticed how zero is categorically different from the other numbers, even the very small ones? It's an additive identity. No matter how often we sum together zeroes, the answer is still zero and that won't work for other values. Being the additive identity is categorically different, even though it might seem as though zero is just even smaller than a tenth or a millionth, it's different. In (safe) Rust we ca…

> In (safe) Rust we categorically don't have type unsafety This is very inaccurate. Simple (i.e. non-dependent) types can describe very, very few properties. 99% of correctness properties cannot be described with simple types at all. That is exactly why, from ATS's vantage point, Rust is about as "safe" as Assembly; its types can guarantee almost nothing, while ATS can guarantee virtually everything. So now the quest…

> After all, Rust doesn't actually give us 100% safety, because we interact with C code etc..

And so, after all this long thread you're back to just saying you weren't actually talking about safe Rust in the conversation about safe Rust. It was all a big waste of my time.

Re: Partially Matching Zig Enums

#155

Post by CyberDildonics »

pron wrote: post #153
CyberDildonics wrote: post #151

Earlier quoted context omitted.

Also, I'm not so sure smart pointers and destructors actually prevent memory leaks Well, they do, that's why people use them. I'm not sure why you would make the case against using another language that makes management manual. Also reference counting cycles are only even possible if you use reference counting in the first place, which isn't necessary for single threaded scope based memory management. Java does preve…

> Well, they do, that's why people use them. They're one of the ways of reducing , not preventing memory leaks. And they're pretty ok at that, but I find other approaches to work better for me.

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 pointers internally that end up referencing each other, which implies a linked list or tree made out of shared pointers, which is essentially a wild mistake huge mistake in the first place. In practice this doesn't really happen.

Re: Partially Matching Zig Enums

#156

Post by pron »

tialaramex wrote: post #154
pron wrote: post #148

Earlier quoted context omitted.

> In (safe) Rust we categorically don't have type unsafety This is very inaccurate. Simple (i.e. non-dependent) types can describe very, very few properties. 99% of correctness properties cannot be described with simple types at all. That is exactly why, from ATS's vantage point, Rust is about as "safe" as Assembly; its types can guarantee almost nothing, while ATS can guarantee virtually everything. So now the quest…

> After all, Rust doesn't actually give us 100% safety, because we interact with C code etc.. And so, after all this long thread you're back to just saying you weren't actually talking about safe Rust in the conversation about safe Rust. It was all a big waste of my time.

No, I was talking about safe Rust, which also interacts with potentially unsafe C code, you know. What do you think schedules the threads running your safe code? How do you think your safe code reads from a socket?

Re: Partially Matching Zig Enums

#157

Post by ViewTrick1002 »

pron wrote: post #156
tialaramex wrote: post #154

Earlier quoted context omitted.

> After all, Rust doesn't actually give us 100% safety, because we interact with C code etc.. And so, after all this long thread you're back to just saying you weren't actually talking about safe Rust in the conversation about safe Rust. It was all a big waste of my time.

No, I was talking about safe Rust, which also interacts with potentially unsafe C code, you know. What do you think schedules the threads running your safe code? How do you think your safe code reads from a socket?

Which as long as no new functionality is added keeps getting safer.

https://security.googleblog.com/2024/09/eliminating-memory-s...

Re: Partially Matching Zig Enums

#158

Post by Ygg2 »

lossolo wrote: post #145
Ygg2 wrote: post #140

Earlier quoted context omitted.

> Sure. With infinite energy, anything’s possible - we can prevent all bugs. The problem is, we don’t have infinite energy. You don't need infinite energy but it is a significant undertaking. The UB seem to obey a power law in regards to their lifetime i.e. every X years number of UB caused problems halves. > I can only recall one serious concurrency bug I’ve ever had (a data race) which took some debugging time to t…

> Even without a chance of UB. You're adding an implicit `Type | null` to every piece that uses nullable code without handling the null case. Each time you forget to do it, you cause either an UB or a null pointer error. And the place it manifests is different from where it's generated. > Furthermore, listening to Tony Hoare's talk ( https://youtu.be/ybrQvs4x0Ps?t=1682 ), he mentions that trying to avoid the null, in…

> Oh, come on, you’re smart enough to understand that a few minutes every few months may not be exactly $0, but it’s such an insignificant value that it can be treated as $0.

You're smart enough to know that just because you sum small things, you can aggregate them over many people and a long time (circa 50 years) to get to massive numbers.

> Well, you can choose your trade offs, and you can let others choose theirs. So I guess you use Ada for everything? or maybe you use Coq to prove everything? Of course you don’t, you’re also making trade offs, just different ones.

Ada doesn't give you full memory safety. I think you need Ada.Spark. I can't find as much teaching material on it, but definitely on my radar. Also, I'm more of a Lean guy myself, but it has a different purpose than Rust. I.e. proving things.

And proofs aren't everything.

Re: Partially Matching Zig Enums

#159

Post by pron »

ViewTrick1002 wrote: post #157
pron wrote: post #156

Earlier quoted context omitted.

No, I was talking about safe Rust, which also interacts with potentially unsafe C code, you know. What do you think schedules the threads running your safe code? How do you think your safe code reads from a socket?

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 guarantee and anything else don't actually believe that, and understand that it's all about numbers and risks. There are many measures to reduce bugs - some through guarantees in the language, others without guarantees - that each have some level of effectiveness and some cost, and the goal is to balance those costs and reduce bugs as much as possible.

Anyone who follows the research in software correctness over the past five decades should know that in the seventies we thought we had the answers, but since the nineties we've known that there is no one right answer to correctness, and that there's no way to tell in advance which methods will be more or less effective.

Re: Partially Matching Zig Enums

#160

Post by pron »

CyberDildonics wrote: post #155
pron wrote: post #153

Earlier quoted context omitted.

> Well, they do, that's why people use them. They're one of the ways of reducing , not preventing memory leaks. And they're pretty ok at that, but I find other approaches to work better for me.

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 realtime safety-critical software, where a missed deadline or a stack overflow means dead people, so I have some grasp on what can really happen.

There's a clear tradeoff between forgetting to write some code and not noticing when code runs when you may not expect it to. Saying that one is universally better than the other is, at the very least, unsubstantiated.

Post reply on HN