Partially Matching Zig Enums

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.

As someone who uses D and has been doing things like what you see in the post for a long time, I wonder why other languages would put attention to these tricks and steal them when they have been completely ignoring them forever when done in D. Perhaps Zig will make these features more popular, but I'm skeptic.

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.

I've seen a few new languages come along that were inspired by zig's comptime/metaprogramming in the same language concept.

Zig I think has potential but it hasn't stabilized enough yet for broad adoption. That means it'll be awhile before it's built an ecosystem (libraries, engines etc.) that is useful to developers that don't care about language design.

Concur. This is a great feature I wish rust had. I've been bitten by the unpleasant syntax this article laments.

> 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 of unsafety (out-of-bounds access) while making the other kind (use-after-free) easier to find.

That the distinction between "fully memory safe" and "not fully memory safe" is binary is also silly not just because of the above, but because no lanugage, not even Java, is truly "fully memory safe", as programs continue to employ components not written in memory safe languages.

Furthermore, Zig has (or intends to have) novel features (among low-level languages) that help reduce bugs beyond those caused by memory unsafety.

If you make advancements but disregard the advancements that came before you, you have a research language, not a modern usable language.

I can't take zig as seriously as rust due to lack of data race safety. There are just too many bugs that can happen when you have threads, share state between those threads and manually manage memory. There are so many bugs I've written because I did this wrong for many years but didn't realize until I wrote rust. I don't trust myself or anyone to get this right.

it can narrow the payload: https://zigbin.io/7cb79d

that doesn't help when you want to run methods or logic on the union type in the switch branch, since you would have to check the tag in every method

it might be helpful for the post to demonstrate that a/b can have different payload types in their example. the reason being on line 9:

  inline .a, .b => |_, ab| {

I think using a concrete example would also be helpful. let's say a bytecode VM, which is top of mind for me right now:

  dispatch: switch (instruction) {
      inline .load0, .load1, .load2, .load3, .load => |_, tag| {
          const slot = switch (tag) {
              .load0 => 0,
              .load1 => 1,
              .load2 => 2,
              .load3 => 3,
              .load => self.read(u8),
              else => comptime unreachable,
          };
          self.locals[slot] = self.pop();
          continue :dispatch self.read(Instruction);
      },
      // ...
  }

I didn't know godbolt let you include URLs. Fascinating: https://raw.githubusercontent.com/uecker/noplate/main/src/co...

I think Zig gets some points here for legibility ;-).

I love the idea, but something being "provable" in this way feels like relying on optimisations.

If a dead code elimination pass didn't remove the 'comptime unreachable' statement, you'll now fail to compile (I expect?)

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

The problem this is meant to solve is that sometimes a human thinking about the logic of the program can see it is impossible to reach some code (ie it is statically certain) but the language syntax and type system alone would not see the impossibility. So you can help the compiler along.

It is not meant for asserting dynamic “unreachability” (which is more like an assertion than a proof).

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!();
            }
        }
    }

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) ?

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

Why would it? If I recall correctly, const and static stuff basically gets inlined at the beginning of the program.