My conclusions

Ultimately I didn't like this language and never even managed to get any use out of it, and everything that I wrote in it got bitrotted away and wasn't worth fixing up. Twice I started Advent of Code with Zig only to quickly switch to some other language midway after getting fed up with it - even Nelua wasn't so frustrating, and even Rust is refreshing by comparison, and even Ada I easily stuck with and got some real use out of. There are some very good ideas and there are some good people, but it's all firmly coming from the school of "when you physically can't see your code anymore through the boilerplate and how long the identifiers are, it'll finally be truly readable and safe", and I subscribe rather to the school of "safety comes from auditability and double-entry bookkeeping".

Zig's obsessions have done more to warm me to its alternatives than to its solutions: actually, exceptions aren't so bad! Actually, duck-typed CTFE isn't so good! Actually, garbage collection isn't so bad! Even Go's error handling is a breath of fresh air after Zig's error handling.

Is it better than C++? Obviously. Is it better than C? ... well, RIP.

comparisons

• vs. rust: assorted thoughts
  1. Zig has much lower cognitive overhead than rust and I'm more able to directly express things I care about.
  2. Zig seems much more likely than rust to achieve very fast feedback loops.
• vs. rust: consistency, mastery, and fun
  1. Rust has many language features and they’re all largely disjoint from each other, so knowing some doesn’t help me guess the others.
  2. I found myself more often in a state of creative flow, devising plans based on the limited capabilities of Zig and then executing them. This flow wasn’t constantly broken by stops for documentation or side-quests to investigate some feature/syntax/library.
• vs. unsafe rust: When Zig is safer and faster than Rust
  1. Rust aside, unsafe Rust is a much, much more painful and less safe language that normal Zig.
  2. Zig was 1.7x faster than Rust because it was too hard in Rust to use pointers instead of a workaround with indices.
• vs. c: Consistency in Zig's Type System (and generics)
• vs. rust: Why I am not ready to switch to Zig just yet
  1. I just don't like comptime, OK?
  2. I had memory troubles that Rust would've prevented.
  3. There are no Zig books.
  theprimagen's commentary.

praise

• Some thoughts on Zig testing - test {} blocks and std.testing are really nice.

manual memory management

• How to actually write C

  And the way we reduce the complexity of difficult problems is through abstraction. So instead of managing the lifetime of individual memory allocations, let’s abstract that, and manage a group of memory allocations. It sounds simple, but depending on how you group allocations, you can literally reduce the number of malloc()’s and free()’s from thousands to a handful.

• Untangled Lifetimes: The Arena Allocator

  My approach, on the other hand, is this: instead of assuming that malloc and free were the correct low-level operations, we can change the memory allocation interface—tweaking what the user and implementation agree on—to simplify the problem and eliminate many of the problems found in the traditional malloc and free style of memory management.

• anonymous malloc rant

  malloc is probably the single biggest reason why software quality has declined over the last thirty years

• std::allocator is to allocation as std::vector is to vexation - CppCon 2015 talk that's "basically the strategy that Zig uses"

tangential

• Why SQLite is coded in C
• The use of assert() in SQLite
• How SQLite is tested
• (no longer tangential, but after all these SQLite links...) Code of Ethics
• What does f(x) mean in C++? (in Zig, it's always some kind of function call, even if a comptime call.)