What Zig felt like, coming from Rust

Zig’s bid to be a “modern C” draws mixed reactions from developers coming from Rust, who weigh its explicit memory management, allocator-centric design and powerful compile-time features against Rust’s stronger safety guarantees and functional-style ergonomics. Many see Zig as attractive for low-level, performance-critical domains where control over allocation and data layout matters, but question whether this is worth giving up Rust’s borrow checker, richer type system and mature tooling. The thread also touches on growing unease with AI-edited technical writing and a broader sense that LLMs are dampening personal enthusiasm for learning new programming languages, even as language design and concepts remain crucial for using these tools effectively.

Zig vs. Rust: Overall Takeaways

  • Many see Zig as modern, fast, and “C-like but nicer,” with strong C/C++ interop and cross-compilation, but clearly younger and rougher than Rust.
  • Rust is framed as an “imperative language with heavy functional influence,” well-suited to a “C++ reimagined” niche, with much more mature tooling and IDE support.
  • Several commenters emphasize that Zig is intentionally lower-level and more explicit than Rust, with no hidden allocation or control flow; others argue Rust can provide equally fine-grained control, just with more safety.

Functional Style vs. Imperative Style

  • Rust’s functional idioms (iterators, map/filter/flat_map, enums, pattern matching, monadic error types) are praised by some as elegant and expressive, especially for API design.
  • Others find heavy iterator chains unreadable and “deranged” compared to plain loops, saying Rust enthusiasts overstate the readability benefits.
  • In Zig, a functional style is possible but often feels impractical because you must explicitly manage allocators; pure transformations can become memory-expensive or bookkeeping-heavy.
  • Debate over “monads” arises mostly around pervasive use of flat_map and combinators; some feel this is a stylistic choice, not a hard language constraint.

Allocators, Arenas, and Memory Management

  • Big subthread on the “allocator obsession” in Zig, Odin, Jai, etc.:
    • Pro side: arenas and custom allocators are crucial in games, kernels, databases, and tight real-time or per-request/per-frame workloads; explicit allocation policies encode important performance decisions.
    • Skeptical side: most real-world software doesn’t need allocator-centric design; generic-over-allocator APIs can be overkill; modern general-purpose allocators (or better malloc implementations) are often enough.
  • Several note that arenas can simplify lifetime management (free in bulk) and reduce manual pointer tracking, but may increase memory usage and complicate structures like hash maps.
  • Zig’s lack of a global allocator forces allocation strategies to be explicit (often via parameters), which some see as a feature and others as noisy.

Compile-Time Features: Zig comptime vs. Rust const

  • Rust aims for compile-time evaluation to behave identically to runtime (same target semantics), which restricts what is allowed (e.g., limited floating-point and traits in const).
  • Zig’s comptime is more powerful and general but may produce results that differ between compile time and runtime, especially for floating-point and platform differences.
  • Some value Rust’s stricter guarantees for reproducible builds; others prefer Zig’s flexibility and find its comptime more effective in practice today.

Tooling and Developer Experience

  • Rust’s tooling (cargo, IDE integration, ecosystem) is generally seen as far ahead.
  • Zig’s command-line tooling and cross-compilation are praised, but lack of robust IDE support is called out as an early, memorable friction point.
  • Some appreciate rediscovering a “CLI-first” workflow and large, self-contained files in Zig.

Language Hype, LLMs, and Motivation

  • Several commenters express diminished excitement about new languages in the LLM era, feeling that detailed language knowledge matters less when AI writes much of the code.
  • Others argue concepts, abstractions, and system design are more important than ever, because you must guide and validate LLM output.
  • There is noticeable annoyance at perceived “AI-isms” in the article’s prose; some suggest writers now need to consciously avoid such tics to appear authentic.

Broader Language Philosophy

  • Some argue there can never be a “true successor to C” because C’s lack of safety features is intentional for “high-level assembly” use; any guardrails change the category.
  • Disagreement over whether systems languages (C, Rust, Zig) should be used for applications at all; some say only OS/low-level code, others point to performance-critical apps (DBs, servers, games) as good fits.
  • Zig is seen as appealing to developers who still like C and want a modern, explicit variant; Rust appeals more to those who want strong safety and abstractions.