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

61–70 of 170 posts

Re: Partially Matching Zig Enums

#61

Post by CyberDildonics »

pron wrote: post #34
tialaramex wrote: post #25

Earlier quoted context omitted.

C++ already illustrates this idea you're talking about and we know exactly where this goes. Rust's false positives are annoying, so programmers are encouraged to further improve the borrowck and language features to reduce them. But the C++ or Zig false negatives just means your program malfunctions in unspecified ways and you may not even notice, so programmers are encouraged to introduce more and more such cases to…

> C++ already illustrates this idea you're talking about and we know exactly where this goes. No, it doesn't. Zig is safer than C++ (and it's much simpler, which also has an effect on correctness). Making up some binary distinction and then deciding that because C++ falls on the same side of it as Zig (except it doesn't, because Zig eliminates out-of-bounds access to the same degree as Rust, not C++) then what applie…

> Zig is safer than C++

Maybe if someone bends over backwards to rationalize it, but not in any real sense. Zig doesn't have automatic memory management or move semantics.

In C++ you can put bounds checking in your data structures and it is already in the standard data structures. You can't build RAII and moves into zig.

Re: Partially Matching Zig Enums

#62

Post by the__alchemist »

dlahoda wrote: post #4

fn main() { if false { const _:() = panic!(); } } Fails to compile in Rust.

I have no idea what that's trying to do. A demonstration that rust is a large language with different dialects! A terse statement with multiple things I don't understand:

  - Assigning a const conditionally?
  - Naming a const _ ?
  - () as a type?
  - Assigning a panic to a constant (or variable) ?
To me it might as well be:

  fn main() {
    match let {
        if ()::unimplemented!() -> else;
    }
}

Re: Partially Matching Zig Enums

#63

Post by conorbergin »

surajrmal wrote: post #52
conorbergin wrote: post #35

Earlier quoted context omitted.

I think the problem with this attitude is the compiler becomes a middle manager you have to appease rather than a collaborator. Certainly there are advantages to having a manager, but if you go off the beaten track with Rust, you will not have a good time. I write most of my code in Zig these days and I think being able to segfault is a small price to pay to never have to see `Arc >>` again.

I can't imagine writing c++ or c these days without static analysis or the various llvm sanitizers. I would think the same applies to zig. Rather than need these additional tools, rust gives you most of their benefits in the compiler. Being able to write bugs and have the code run isn't really something to boast about.

I would rather rely on a bunch of sanitizers and static analysis because it is more representative of the core problem I am solving: Producing machine code. If I want Rust to solve these problems for me I now have to write code in the Rust model, which is a layer of indirection that I have found more trouble than it's worth.

Re: Partially Matching Zig Enums

#64

Post by Sytten »

conorbergin wrote: post #35
Sytten wrote: post #20

Earlier quoted context omitted.

This is really the crust of the argument. I absolutely love the Rust compiler for example, going back to Zig would feel a regression to me. There is a whole class of bugs that my brain now assumes the compiler will handle for me.

I think the problem with this attitude is the compiler becomes a middle manager you have to appease rather than a collaborator. Certainly there are advantages to having a manager, but if you go off the beaten track with Rust, you will not have a good time. I write most of my code in Zig these days and I think being able to segfault is a small price to pay to never have to see `Arc >>` again.

I view it as a wonderful collaborator, it tells me automatically were my code is wrong and it gets better with every release, I can't complain really. I think a segfault is a big price to pay, but it depends on the criticality of it I guess.

Re: Partially Matching Zig Enums

#65

Post by Sytten »

pron wrote: post #23
Sytten wrote: post #20

Earlier quoted context omitted.

This is really the crust of the argument. I absolutely love the Rust compiler for example, going back to Zig would feel a regression to me. There is a whole class of bugs that my brain now assumes the compiler will handle for me.

Problem is, like they say the stock market has predicted nine of the last five recessions, the Rust compiler stops nine of every five memory safety issues. Put another way, while both Rust and Zig prevent memory safety issues, Zig does it with false negatives while Rust does it with false positives. This is by necessity when using the type system for that job, but it does come at a cost that disqualifies Rust for oth…

So far I think the adoption in critical infrastructure (Linux, AWS, Windows, etc.) is clearly in Rust favor but I agree that something at some point will replace Rust. My belief is that more guardrails will end up winning no matter the language since the last 50 years of progamming have shown us we can't rely on humans to write bug free code and it is even worse with LLM.

Re: Partially Matching Zig Enums

#66

Post by Sytten »

munchler wrote: post #43
Sytten wrote: post #20

Earlier quoted context omitted.

This is really the crust of the argument. I absolutely love the Rust compiler for example, going back to Zig would feel a regression to me. There is a whole class of bugs that my brain now assumes the compiler will handle for me.

Nit: I think you want crux in that phrase, not crust .

Thanks! Cant edit anymore, I guess I was feeling hungry this morning

Re: Partially Matching Zig Enums

#67

Post by pron »

CyberDildonics wrote: post #61
pron wrote: post #34

Earlier quoted context omitted.

> C++ already illustrates this idea you're talking about and we know exactly where this goes. No, it doesn't. Zig is safer than C++ (and it's much simpler, which also has an effect on correctness). Making up some binary distinction and then deciding that because C++ falls on the same side of it as Zig (except it doesn't, because Zig eliminates out-of-bounds access to the same degree as Rust, not C++) then what applie…

> Zig is safer than C++ Maybe if someone bends over backwards to rationalize it, but not in any real sense. Zig doesn't have automatic memory management or move semantics. In C++ you can put bounds checking in your data structures and it is already in the standard data structures. You can't build RAII and moves into zig.

> Maybe if someone bends over backwards to rationalize it, but not in any real sense.

In a simple, real sense. Zig prevents out-of-bounds access just as Rust does; C++ doesn't. Interestingly, almost all of Rust's complexity is invested in the less dangerous kind of memory unsafety (https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html).

> You can't build RAII and moves into zig.

So RAII is part of the definition of memory safety now?

Why not just declare memory safety to be "whatever Rust does", say that anything that isn't exactly that is worthless, and be done with that, since that's the level of the arguments anyway.

We could, of course, argue over which of Rust, Zig, and C++ offers the best contribution to correctness beyond the sound guarantees they make, except these are empirical arguments with little empirical data to make any determination, which is part of my point.

Software correctness is such a complicated topic and, if anything, it's become more, not less, mysterious over the decades (see Tony Hoare's astonishment that unsound methods have proven more effective than sound methods in many regards). It's now understood to be a complicated game of confidence vs cost that depends on a great many factors. Those who claim to have definitive solutions don't know what they're talking about (or are making unfounded extrapolations).

Re: Partially Matching Zig Enums

#68

Post by pron »

rowanG077 wrote: post #57
pron wrote: post #48

Earlier quoted context omitted.

> Unless you actually use the simplicity to apply formal methods I don't think simplicity make a language safer. That depends what you mean by "safer", but it is an empirical fact that unsound methods (like tests and code reviews) are extremely effective at preventing bugs, so the claim that formal methods are the only way is just wrong (and I say this as a formal methods guy, although formal methods have come a long…

> That depends what you mean by "safer", but it is an empirical fact that unsound methods (like tests and code reviews) are extremely effective at preventing bugs, so the claim that formal methods are the only way is just wrong (and I say this as a formal methods person) I agree that tests and reviews are somewhat effective. That's not the point. The point is that if you look at the history of programming languages s…

> The point is that if you look at the history of programming languages simplicity in general goes against safety... C and assembly are extremely simple compared to java, python, C#, typescript

But Java and Python are simpler yet safer than C++, so I don't understand what trend you can draw if there are examples in both directions.

> It's the greatest example of you take a simple language, you add a ton of complexity and it becomes more safe.

But I didn't mean to imply that's not possible to add safety with complexity. I meant that when the sound guarantees are the same in two languages, then there's an argument to be made that the simpler one would be easier to write more correct programs in. Of course, in this case Zig is not only simpler than C++, but actually offers more sound safety guarantees.

Re: Partially Matching Zig Enums

#69

Post by Ygg2 »

hitekker wrote: post #33
pron wrote: post #21

Earlier quoted context omitted.

> just another memory unsafe language Also, treating all languages that don't ensure full memory safety as if they're equally problematic is silly. The reason not ensuring memory safety is bad is because memory unsafety as at the root of some bugs that are both common, dangerous, and hard to catch. Only not all kinds of memory unsafety are equally problematic, Zig does ensure the lack of the the most dangerous kind o…

If you one day write a blog, I would want to subscribe. Your writing feels accessible. I find it makes complex topics approachable. Or at least, it gives me a feel of concepts that I would otherwise have no grasp on. Other online writing tends to be permeated by a thick lattice of ideology or hyper-technical arcanery that inhibits understanding.

> Your writing feels accessible. I find it makes complex topics approachable

Yeah. By omitting a large swath of nuance. It reeks of "you can approximate cow with a sphere the size of Jupiter". It's baffling ludicrous.

Any rhetorical device that equates Java/C# (any memory safe Turing language ) safety with C is most likely a fallacy.

Post reply on HN