Interview with Zig language creator Andrew Kelley [video]

I think that Zig's simplicity hides how revolutionary it is, both in design and in potential. It reminded me of my impression of Scheme when I first learned it over twenty years ago. You can learn the language in a day, but it takes a while to realize how exceptionally powerful it is. But it's not just its radical design that's interesting from an academic perspective; I also think that its practical goals align with mine. My primary programming language these days is C++, and Zig is the first low-level language that attempts to address all of the three main problems I see with it: language complexity, compilation speed, and safety.

In particular, it has two truly remarkable features that no other well-known low-level language -- C, C++, Ada, and Rust -- have or can ever have: lack of macros and lack of generics (and the associated concepts/typeclasses) [1]. These are very important features because they have a big impact on language complexity. Despite these features, Zig can do virtually everything those languages do with macros [2] and/or generics (including concepts/typeclasses), and with the same level of compile-time type safety and performance: their uses become natural applications of Zig's "superfeature" -- comptime.

Other languages -- like Nim, D, C++ and Rust also have a feature similar to Zig's comptime or are gradually getting there -- but what Zig noticed was that this simple feature makes several other complex and/or potentially harmful features redundant. Antoine de Saint-Exupery said that "perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." I think that Zig, like Scheme -- and yes, there are others -- is close to that minimalist vision of perfection.

What a truly inspiring language. Rather than asking how we could make C++'s general philosophy work better as another increasingly famous language does, IMO, it asks how we could reshape low-level programming in a way that's a more radical break with the past. I think it's a better question to ask. Now all there's left to hope for is that Zig gets to 1.0 and gains some traction. I, for one, would love to find a suitable alternative to C++, and I believe Zig is the first language that could achieve that in a way that suits my particular taste.

[1]: I guess C has the second feature, but it loses both expressivity and performance because of it.

[2]: Without the less desirable things people can do with macros.

> Other languages -- like Nim, D, C++ and Rust also have a feature similar to Zig's comptime or are gradually getting there -- but what Zig noticed was that this simple feature makes several other complex and/or potentially harmful features redundant.

I'm curious where this impression of Zig comes from, as this is precisely what Nim has set out to do: a small core extensible via metaprogramming. Are there features that Nim implements which go against this premise? if so, what are they? :)

> Are there features that Nim implements which go against this premise? if so, what are they? :)

Nim has generics (plus concepts), templates, and macros. Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim.

---

Also, note another remarkable feature. One could define a language called Zig' with the following properties:

1. Every well-formed Zig program is a well-formed Zig' program (i.e. Zig' accepts all Zig programs, potentially more).

2. Every Zig program has the same semantics as the identical program when interpreted in Zig'.

This means that to analyse the semantics of a Zig program you can pretend it's a Zig' program; in fact, you don't need to create an interpreter for Zig', you can just pretend it exists. Why would you want to do that? Because Zig' is simpler. How? Here's the kicker: Zig' ignores comptime completely. It is a very simple, optionally-typed, dynamic language with reflection.

In other words, to analyse the semantics of a Zig program you can forget about comptime and pretend it can do everything at runtime (and treat comptime as a pure semantics-preserving optimisation).

This is not true for languages with macros, as they are not "erasable".

> Zig has just comptime, through which it achieves all those goals (minus some macro capabilities that it deems harmful anyway) with just one, very simple, cohesive construct. You could argue on whether you like this or not, but you can't argue that Zig's approach isn't fundamentally more minimal. Zig is a language you can reasonably fully learn in one day; I don't think you could say the same about Nim.

"some macros" are downplaying Nim macros, it's like saying Lisp has some AST rewrite capabilities.

Nim macros goals are two-folds:

1. adding functionality to the language without baking it in the compiler. A prime example is ``async``, ``async`` including a nice async/await syntax can be completely implemented as a library without reserving keywords to do things like `pub async fn`.

2. Automating away boilerplate.

From what I understood, Zig comptime is only about making compile-time function evaluation first-class.

Yes, plus introspection. Zig tries very, very hard to avoid macros, so macros are an anti-feature from Zig's perspective. That you could do what Zig finds important for its domain, like conditional compilation, writing a typesafe println, generic types, and generating pretty-printing routines all in simple Zig without macros is a cool discovery. I don't know if it's true, but I think the desire to avoid macros at all cost was a bigger motivation for Zig's design than, say, generic types.

In other words, there is a capability here that Nim really, really wants, and that Zig really, really doesn't want, so on that front they are not competing in their designs.

I do love how zig's comptime naturally led to generics without extra syntax. But after using nim i'm convinced that macros make even more sense for systems programming. They can even affect performance -- nim's macros can generate types that would be difficult to write by hand.

I also take issue with your statement that zig is "more minimal" since that only applies to the user's perspective -- from the compiler's perspective, macros make a language far more minimal. But i vaguely recall already discussing this distinction with you so i don't want to rehash it.

At any rate i will definitely be paying attention to andrew's progress, he has a really clear vision.

> But after using nim i'm convinced that macros make even more sense for systems programming.

Macros are controversial. I love them in Scheme and Clojure, but I wouldn't want them in any language aimed at a larger, more mainstream crowd. At the very least, macros introduce another meta-language to know (and if they're in a language with a complex type-level language like Rust or Haskell then they're a third language within the language), but I think it's a matter of personal aesthetic preference.

> But i vaguely recall already discussing this distinction with you so i don't want to rehash it.

Maybe we did. :)

Look at any sufficiently complex and/or low level C like Linux or FreeRTOS, and C text macros are used significantly. Some of the functionality would be horrible to implement otherwise. Being text based they're a pain, but like @gw, I'd have a hard time seeing a language like Zig without macros making a good low level system language. Maybe a good systems application like Kubernetes, similar to Go's niche, but not system kernels.

The goal isn't to have macros but to be able to do what macros are used for. Zig has found a different and simpler way to do what macros do. comptime gives you generic types, typeclasses/concepts, typesafe printf, conditional compilation and much more, all without macros and with a simpler construct than macros.

After reading your previous comment, I read a bit more about comptime. It does seem to be able to handle most of the cases I could think of wanting macros for, and it is a nice UX in that it's really like "bounded macros" and prevents building arbitrary new semantics. Though thinking on two levels in a given function does seem tricky to me, but perhaps that's just familiarity. Personally, I kind of like having separate macro vs code. Comptime seems like it'd almost be a better fit for Go than their generics proposal.

The beauty of comptime is that, unlike with macros, you don't need to think on two levels. The semantics is the same as if everything were done at runtime. To read a comptime function you can completely ignore the distinction between compilation time and runtime. To write it you need to know that some operations are only available at compile-time.

See my comment here about "Zig' ": https://news.ycombinator.com/item?id=24293611

Perhaps now you see what I meant when I said that Zig's simplicity hides its radical design.