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

31–40 of 170 posts

Re: Partially Matching Zig Enums

#31

Post by dlahoda »

Sharlin wrote: post #12
dlahoda wrote: post #4

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

Sure, because it's compile-time code inside a (semantically) run-time check. In recent Rust versions you can do fn main() { const { if false { let _:() = panic!(); } } } which compiles as expected. (Note that if the binding were `const` instead of `let`, it'd still have failed to compile, because the semantics don't change.)

not sure it is to be equivalent to zig.

in zig they have one brach const.

in rust example from you, whole control flow ix is const. which is not rquivalent to zig. so how to have non const branches?

Re: Partially Matching Zig Enums

#32

Post by ozgrakkurt »

judofyr wrote: post #7

This is one the reasons I find it so silly when people disregard Zig «because it’s just another memory unsafe language»: There’s plenty of innovation within Zig, especially related to comptime and metaprogramming. I really hope other languages are paying attention and steals some of these ideas. «inline else» is also very powerful tool to easily abstract away code with no runtime cost.

This perspective that many people take on memory-safety of Rust seems really "interesting".

Unfortunately for all fanatics, language really doesn't matter that much.

I have been using KDE for years now and it works perfectly good for me. It has no issues/crashes, it has many features in terms of desktop environment and also many programs that come with it like music player, video player, text editor, terminal etc. and they all work perfectly well for me. Almost all of this is written in C++. No need to mention the classic linux/chromium etc. etc which are all written in c++/c.

I use Ghostty which is written in zig, it is amazingly polished and works super well as well.

I have built and used a lot of software written in Rust as well and they worked really well too.

At some point you have to admit, what matters is the people writing software, the amount of effort that goes into it etc. it is not the langauge.

As far as memory-safety goes, it really isn't close to being the most important thing unless you are writing security critical stuff. Even then just using Rust isn't as good as you might think, I uncountered a decent amount of segfaults, random crashes etc. using very popular Rust libraries as well. In the end just need to put in the effort.

I'm not saying language doesn't matter but it isn't even close to being the most important thing.

Re: Partially Matching Zig Enums

#33

Post by hitekker »

pron wrote: post #21
judofyr wrote: post #7

This is one the reasons I find it so silly when people disregard Zig «because it’s just another memory unsafe language»: There’s plenty of innovation within Zig, especially related to comptime and metaprogramming. I really hope other languages are paying attention and steals some of these ideas. «inline else» is also very powerful tool to easily abstract away code with no runtime cost.

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

Re: Partially Matching Zig Enums

#34

Post by pron »

tialaramex wrote: post #25
pron wrote: post #23

Earlier quoted context omitted.

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…

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 applies to one must apply to the other. There is simply no justification to make that equivalence.

> There is no middle choice here, that's Rice's Theorem, non-trivial semantic correctness is Undecidable.

That's nothing to do with Rice's theorem. Proving some properties with the type system isn't a general algorithm; it's a proof you have to work for in every program you write individually. There are languages (Idris, ATS) that allow you to prove any correctness property using the type system, with no false positives. It's a matter of the effort required, and there's nothing binary about that.

To get a sense of the theoretical effort (the practical effort is something to be measured empirically, over time) consider the set of all C programs and the effort it would take to rewrite an arbitrary selection of them in Rust (while maintaining similar performance and footprint characteristics). I believe the effort is larger than doing the same to translate a JS program to a Haskell program.

Re: Partially Matching Zig Enums

#35

Post by conorbergin »

Sytten wrote: post #20
chrismorgan wrote: post #19

Earlier quoted context omitted.

What I’ve seen isn’t people disregarding Zig because it’s just another memory-unsafe language, but rather disqualifying Zig because it’s memory-unsafe, and they don’t want to deal with that, even if some other aspects of the language are rather interesting and compelling. But once you’re sold on memory safety, it’s hard to go back.

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.

Re: Partially Matching Zig Enums

#36

Post by pron »

IshKebab wrote: post #26
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…

Right but I think people are disappointed because we finally got a language that has memory safety without GC, so Zig seems like a step backwards. Even if it is much much better than C (clearly), it's hard to get excited about a language that "unsolves" a longstanding problem. > not even Java, is truly "fully memory safe", as programs continue to employ components not written in memory safe languages. This is a silly…

> I think people are disappointed because we finally got a language that has memory safety without GC, so Zig seems like a step backwards

Memory safety (like soundly ensuring any non-trivial property) must come at a cost (that's just complexity theory). You can pay for it with added footprint (Java) or with added effort (Rust). Some people are disappointed that Zig offer more safety than C++ but less than Rust in exchange for other important benefits, while others are disappointed that the price you have to pay for even more safety in Rust is not a price they're happy to pay.

BTW, many Rust programs do use GC (that's what Rc/Arc are), it's just one that optimises for footprint rather than speed (which is definitely okay when you don't use the GC as much as in Java, but it's not really "without GC", either, when many programs do rely on GC to some extent).

> This is a silly point.

Why? It shows that even those who wish to make the distinction seem binary themselves accept that it isn't, and really believe that it matters just how much risk you take and how much you pay to reduce it.

(You could even point out that memory corruption can occur at the hardware level, so not only is the promise of zero memory corruption not necessarily worth any price, but it is also unattainable, even in principle, and if that were truly the binary line, then all of software is on the same side of it.)

Re: Partially Matching Zig Enums

#37

Post by Eliah_Lakhin »

ozgrakkurt wrote: post #32
judofyr wrote: post #7

This is one the reasons I find it so silly when people disregard Zig «because it’s just another memory unsafe language»: There’s plenty of innovation within Zig, especially related to comptime and metaprogramming. I really hope other languages are paying attention and steals some of these ideas. «inline else» is also very powerful tool to easily abstract away code with no runtime cost.

This perspective that many people take on memory-safety of Rust seems really "interesting". Unfortunately for all fanatics, language really doesn't matter that much. I have been using KDE for years now and it works perfectly good for me. It has no issues/crashes, it has many features in terms of desktop environment and also many programs that come with it like music player, video player, text editor, terminal etc. an…

> As far as memory-safety goes, it really isn't close to being the most important thing unless you are writing security critical stuff.

Safety is the selling point of Rust, but it's not the only benefit from a technical point of view.

The language semantics force you to write programs in a way that is most convenient for the optimizing compiler.

Not always, but in many cases, it's likely that a program written in Rust will be highly and deeply optimized. Of course, you can follow the same rules in C or Zig, but you would have to control more things manually, and you'd always have to think about what the compiler is doing under the hood.

It's true that neither safety nor performance are critical for many applications, but from this perspective, you could just use a high-level environment such as the JVM. The JVM is already very safe, just less performant.

Re: Partially Matching Zig Enums

#38

Post by pron »

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.

Thank you!

I did have one once (https://pron.github.io) but I don't know how accessible it is :) (two post series are book-length)

Re: Partially Matching Zig Enums

#39

Post by sekao »

veber-alex wrote: post #24

I don't understand. Isn't this only useful if the value you match on is known at compile time?

The code example will work even if `u` is only known at runtime. That's because the inner switch is not matching on `u`, it's matching on `ab`, which is known at compile time due to the use of `inline`.

That may be confusing, but basically `inline` is generating different code for the branches .a and .b, so in those cases the value of `ab` is known at compile time. So, the inner switch is running at compile time too. In the .a branch it just turns into a call to handle_a(), and in the .b branch it turns into a call to handle_b().

Re: Partially Matching Zig Enums

#40

Post by pron »

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.

Not to mention that `Arc` uses a GC (and not a stellar one, at that)...
Post reply on HN