Things Zig comptime won't do

Overall reactions to the post and comptime mechanics

• Many found the article clarifying, especially the distinction between comptime for and inline for (length-known-at-compile-time loops vs introspective loops, often used for struct-field iteration rather than performance).
• Readers highlight Zig’s “fluid” workflow: when you need type info, you propagate a comptime type parameter; when you can’t, you’re forced to rethink design.
• The key selling point: types and other compile‑time values are just values in the language, but only at compile time, with referentially transparent behavior (no access to raw syntax/identifiers).

Zig’s positioning vs C, C++, and Rust

• Several see Zig as “better C”: removing UB, replacing macros with comptime, strong C interop, and a C compiler built in.
• There’s disagreement whether Zig aims to extend C or ultimately replace it; some stress “if a C library works, use it”, others note emerging “pure Zig” rewrites and some hostile rhetoric toward POSIX/C.
• Some want a “strict/safety mode” closer to Rust’s guarantees; others accept Zig’s lower safety in exchange for ergonomics and simpler mental model.
• Zig is seen as a good C replacement but a weaker C++ replacement due to lack of RAII/ownership system; Rust is preferred for that niche.

Rust’s safety model and ergonomics debate

• Long subthread on Rust’s borrow checker: proponents say it makes refactoring safer; critics find it un-fun and obstructive when the compiler rejects code they “know” is correct.
• Pain points mentioned: mutually-referential structures, lifetimes “infecting” APIs, self-referential types, single-threaded mutation with later multithreaded sharing, and indices vs references tradeoffs.
• Broader point: you can’t have zero runtime overhead, full aliasing, and memory safety without accepting strict paradigms (e.g., Rust) or GC; different people want different tradeoffs.

Is Zig’s comptime actually novel?

• One camp: Zig’s novelty is not CTFE itself (D, Nim, Julia, Lisp, Rust macros already have powerful compile-time facilities), but that Zig uses one partial‑evaluation mechanism instead of separate features: templates/generics, interfaces/typeclasses, macros, conditional compilation.
• Opposing view: Zig’s comptime only approximates those features; it’s more duck-typed and less declarative than e.g. Java/Haskell generics, so type errors surface only at instantiation and constraints aren’t explicit.
• Comparisons with D’s CTFE and templates led to debate over whether Zig is truly revolutionary or largely a different packaging of ideas already explored in D and others.

Build-time codegen, macro power, and host/target concerns

• Some complain that Zig’s restricted comptime pushes people into zig build-time string codegen plus @import, effectively creating a hidden macro stage.
• Others strongly prefer IO and non-determinism to live in the build system, not the compiler, to preserve reproducible, host‑agnostic compilation.
• Clarification: Zig’s comptime evaluation conceptually runs “on the target”: platform properties (pointer size, endianness, struct layout) reflect the target, not the host, which is crucial for reliable cross‑compilation.
• Multiple comments generalize: metaprogramming is powerful but often overused; partial evaluation, higher‑order functions, and simple generics are usually preferable to complex macro systems.