As of 20240404 (zig version 0.12.0-dev.3562+96bc8f17c)

20240701 (zig version 0.14.0-dev.4234+1e3fb4825), Zig provides one of the best possible semantics to optimize memory details, while offering widely portable source code with reasonable safety in a relative concise and readable way.

Aside of signaling for toolings, I found personally no major annoying parts.
For example, picking up nested slices and some build system parts might be inconvenient, but those are one time things and no footguns.

The rest of the language feels very smooth to me in contrast to the potential very flexible and cryptic syntax of C (see preprocessor iceberg).

• Bottlenecks of array assignments not obvious via @memcpy.
  

  test "perf array assignment" {
      const x: u8 = 100;
      const x: [1_000_000]u8 = .{x} ** 1_000_000;
      var b: [1_000_000]u8 = undefined;
      // pile of code
  
      b = a; // spot the performance issue
  
      // pile of code
  }

• Signaling: Test runner allows no signaling to qemu -g 4242 (debugger mode). Qemu uses gdb server signaling, which means sending SIGKILL is necessary to kill the debugging server process.
• Memory, aliasing and pointer semantics: Zig inherits from LLVM potential miscompilations due to longstanding provenance and aliasing bugs.
  • Zig upstream issue
  • LLVM upstream issue
  • Related Rust RFC
  • Related gcc issue
  (Updated 20240701)
• Weak memory semantics: Zig inherits from LLVM the same class of problems from the C11 memory model. As of 20240701, and take below statements with a big grain of salt, since I did not check thoroughly common vendors and I do mostly rely on talks from ACM SIGPLAN FOWM'24 and "Multicore Semantics: Making Sense of Relaxed Memory".
  1. There is nothing conclusive on how the "out of thin air problem" should be fixed, which is problematic for reasoning with weak memory.
  2. Many hardware architectures have no sufficiently ISA-complete (and formally verified) synchronization models.
  3. There is no official test corpus to stress test architectures by vendors or third parties.
  4. There is no official test corpus with code and optimization models to test formal model influence of example code.
  5. There is no debugging tooling to identify and trace or track down synchronization bugs from weak memory (in production) or vendor recommended strategies to stress test on their platforms (derived from the formal models of the architecture).
  (Updated 20240701)