Zig's Lovely Syntax

Original Article ↗ Hacker News Discussion ↗

Parsing quirks and “noisy” syntax

  • Some find Zig’s parser too strict: e.g. needing a space before orelse and unclear errors when structs aren’t wrapped in .{}; this is especially painful for people with RSI.
  • Several commenters describe Zig as visually noisy, disliking @TypeOf, .{} literals, and sigils like @ and leading .. Others say this “brutalist” style improves predictability and removes surprises.

Struct literals, .{}, and type inference

  • Defenders of .{} / .x = argue it avoids redundant type names in nested initializations and is less noisy than Rust’s explicit Type { field: ... }.
  • Critics note a planned removal of explicit T{} weakens the “dot means inferred type” story and makes code harder to navigate and click-through.
  • Debate over whether the leading . in .{} is worth the parsing convenience; some would prefer dropping it.
  • There’s comparison with C99’s designated initializers as a “gold standard” that Zig and Rust still don’t fully match.

Lambdas, closures, and runtime polymorphism

  • Zig’s lack of lambdas/closures surprises developers coming from C++/Rust. Common workaround is named functions plus an explicit “context” parameter or manually defined vtables.
  • Supporters say this keeps allocation and control flow explicit and avoids hidden heap use; critics counter that capturing needn’t imply heap allocation (citing C++/Rust), and manual vtables are verbose.
  • Function syntax (fn foo(a: i32) i32) is seen by some as blocking elegant lambda/arrow forms; others note Go manages anonymous functions with a similar declaration style.

Multiline strings and line comments

  • Zig’s multiline raw strings using \\ prefixes spark strong reactions.
  • Proponents argue it’s a clean, indentation-safe solution that keeps newlines unambiguous, and becomes comfortable with tooling and highlighting.
  • Opponents find it visually “insane”, confusing next to // comments, and prefer traditional """/backtick/“dedent” schemes used in Kotlin, Go, Java, C#, etc.

Type placement, let-style binds, and tooling

  • Ongoing type-syntax debate: some prefer name: Type (Rust/Zig/Pascal style) for parsing simplicity; others want Type name for faster visual type lookup.
  • There’s tension between designing for greppability vs assuming advanced IDEs; some insist CLI grep/ripgrep is still crucial on large codebases, others argue IDE search is strictly superior.
  • Concerns are raised that heavy comptime and inferred types may be unfriendly to LSP/intellisense.

Other syntactic/design flashpoints

  • No operator overloading is seen as blocking “lovely” vector/matrix syntax; suggestion of explicit overloaded operators (like #+) meets pushback over symbol soup.
  • Some praise Zig’s try/catch and loop-as-expression model; others miss Rust-like implicit block returns, optional-chaining (a?.b?.c), and monadic-style APIs.
  • Meta-thread: many argue syntax does matter as the primary interface to a language, but preferences are highly subjective; several compare Zig unfavorably to Kotlin, Go, Ruby/Crystal, or D, while others emphasize Zig is “fun to write” and more readable in large, industrial code.