[pron]

What is checked at compile-time in Zig is up to the Zig code. It's a little hard to explain because this doesn't work like Lisp (or Rust) macros, but, since Zig is so easy to learn -- despite this revolutionary design -- should mean it's not a problem. As a first approximation (somewhat inaccurate), you could think of Zig as an optionally typed dynamic language that can run introspect (and create) types freely, perform elaborate checks on them etc. (e.g. examine fields and their types, and compare them to other types' fields), and then the programmer gets to say: run these checks at compile-time and make errors compilation errors.

[The_rationalist]

Note that c++ and rust have const fn. But yeah the dinamicity and introspectabibility you describe reminds me of typescript.

[pron]

It's not about what Zig has but what it doesn't have. Because low-level programming is already complex, language simplicity is a super-important feature that few low-level languages have, and I would say none that are expressive and emphasise safety -- except Zig.

You could do those things in C++ with template games and in Rust with macros. But Zig lets you have immense expressivity with a simple, small and easy-to-learn language.

[leshow]

> You could do those things in C++ with template games and in Rust with macros. But Zig lets you have immense expressivity with a simple, small and easy-to-learn language.

const fn is (or seems to me to be) exactly what comptime is though. The difference is that rust's const syntax is still slowly allowing more things to be executed at compile time. Like for now, it still can't do any heap allocation.

[pron]

Zig's unique power and killer feature isn't having comptime; it's having little else. That's a feature C++ or Rust or D or Nim simply can never, ever have, and it's an extremely important feature, especially in low-level programming. You can do in C++ anything you can do in Zig; but you can't do those things in a simple language you can quickly learn and fully grasp.

[leshow]

Take this with a grain of salt but from the little examples I've seen it looks like a nightmare for any type of large application. I would much rather have increased power in the type system rather than having arbitrary code run and fail builds in an ad-hoc fashion.

[pron]

It isn't "arbitrary code." It is strictly less arbitrary and ad-hoc than Rust's macros. You can think of it more as a programmable type system, although that, too, is not very precise. As to maintenance of large codebases, it is far too early to tell, of course, but note that no low-level programming language has a great record on that front. I think it is because components in such languages are much more sensitive to the implementation details of others (i.e. all those languages have very low abstraction, i.e. the ability to hide and isolate internal implementation details), but low-level programmers know this comes with the territory, and is part of the price you pay for a high-level of control over low-level details.

[craftinator]

> It's not about what Zig has but what it doesn't have. Because low-level programming is already complex, language simplicity is a super-important feature

This is what made me love Lua for embedded programming. The more inherent complexity (or "exposed complexity" might be a better phrase) in the system, the less inherent complexity you want in the language.