Why Zig When There Is Already C++, D, and Rust?

Article updates & scope

• Original Zig comparison page was updated to fix outdated points, notably the lack of a package manager.
• Some commenters feel the page lists features but doesn’t clearly say “use Zig if you’re doing X,” making it harder to decide for specific domains like scientific computing.

Hidden control flow & control flow definition

• Large subthread debates what “control flow” means: some restrict it to conditionals; others include any change in execution order (function calls, exceptions, interrupts, gotos).
• Zig’s “no hidden control flow” is interpreted as “no invisible function calls or exception-based jumps”: you should see all branching and error propagation at the call site.
• Critics argue features like defer/try themselves are non-obvious control-flow keywords and the term “hidden” is overloaded.

Memory allocation & allocators

• Passing allocators explicitly is defended as inversion of control and avoids “function color” problems.
• Some see the extra parameters as mild overhead; global allocators remain an option.
• Concern: libraries could still create their own allocators or call the OS directly. Defenders say this would be unidiomatic in Zig.
• Capability-based designs in other languages are mentioned; participants argue this is hard/impossible to enforce in a “no runtime” systems language like Zig.

Error handling & exceptions

• Zig’s try/error unions force handling or explicit propagation at call sites, contrasting with hidden exceptions in C++/Java and panics in Go/Rust.
• Some see inline error handling as noisy; others say Zig’s try is lightweight and clearer than checked exceptions.
• Debate over whether Go’s panic/recover counts as exceptions; some insist they’re “poor man’s exceptions.”

RAII, destructors, and resource cleanup

• Lack of RAII/destructors is a major deal-breaker for several participants, who see explicit cleanup calls as verbose and error-prone.
• Others prefer explicit lifetimes, defer, and allocator patterns, arguing they make cleanup points clearer and encourage designs that don’t require destructors.
• Rust’s RAII model is cited as an appealing middle ground.

Operator overloading, abstractions, and math/strings

• No operator overloading is praised as avoiding “hidden calls” and over-clever DSLs.
• Opponents say it hurts numeric and linear-algebra code and makes string concatenation and custom numerics clumsier; +/~ style syntax in other languages is seen as more ergonomic.
• Pro-Zig side argues abstractions should be explicit functions; critics reply that “fewer footguns” can be overvalued compared to expressiveness.

Use cases and target audience

• Supporters highlight Zig’s simplicity, optional standard library, and freestanding design as ideal for kernels, embedded, EFI, and low-level systems work.
• Some see promise for game development and tooling (e.g., terminal emulators, web runtimes); others doubt its fit for high-level, math-heavy or enterprise-style codebases.

Stability, ecosystem, and adoption risk

• Discussion over language stability timelines and whether it’s wise to bet on Zig before 1.0.
• One side stresses that early adopters risk migration costs, comparing to Rust’s pre-1.0 churn and Python 2→3; another side notes growing real-world use (e.g., web tooling, trading systems) as evidence Zig is more than a toy.
• There’s tension between wanting C interop and guarantees: heavy C reuse undermines some of Zig’s safety/story.

Comparisons with D, Rust, Go, Jai, C, etc.

• D users report good performance and multiple allocation strategies, and see little reason to switch based solely on the page.
• Rust is praised for safety but criticized for complexity, tooling issues, and lack of allocator API / portable SIMD; some Rust users are “Zig-curious.”
• Go’s lack of try/catch is pointed out; its panics are rarely used for control flow but do hide allocations (e.g., defer).
• Jai is discussed but dismissed for now due to being closed/unreleased and lacking 32-bit embedded support.
• Some argue C or C-like successors (C3, others) are still simpler; others counter that C’s simplicity hides a large gap between “can write C” and “can write safe, correct C.”