Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things Zig comptime won't do

matklad.github.io

Post reply on HN
Print view View original

191–200 of 252 posts

Re: Things Zig comptime won't do

#191

Post by CRConrad »

baazaa wrote: post #142
msteffen wrote: post #115

Earlier quoted context omitted.

If I understand TFA correctly, the author claims that D’s approach is actually different: https://matklad.github.io/2025/04/19/things-zig-comptime-won... “In contrast, there’s absolutely no facility for dynamic source code generation in Zig. You just can’t do that, the feature isn’t! [sic] Zig has a completely different feature, partial evaluation/specialization, which, none the less, is enough to cover most of use-c…

that's a comically archaic way of using the verb 'to be', not a grammatical error. you see it in phrases like "to be or not to be", or "i think, therefore i am". "the feature isn't" just means it doesn't exist.

Damn, beat me by half a day.

Re: Things Zig comptime won't do

#192

Post by matklad »

pcwalton wrote: post #187
naasking wrote: post #180

Earlier quoted context omitted.

> Zig's use of comptime in a function argument makes it a template :-/ That you can draw an isomorphism between two things does not mean they are ergonomically identical.

When we're responding to quite valid points about other languages having essentially the same features as Zig with subjective claims about ergonomics, the idea that Zig comptime is "revolutionary" is looking awfully flimsy. I agree with Walter: Zig isn't doing anything novel. Picking some features while leaving others out is something that every language does; if doing that is enough to make a language "revolutionary…

>for Zig enthusiasts, the set of features that Zig has appeals to them. Just like enthusiasts of every programming language.

I find it rather amusing that it's a Java and a Rust enthusiast who are extolling Zig approach here! I am not particularly well read with respect to programming languages, but I don't recall many languages which define generic pair as

    fn Pair(A: type, B: type) type {
        return struct { fst: A, snd: B };
    }
The only one that comes to mind is 1ML, and I'd argue that it is also revolutionary.

Re: Things Zig comptime won't do

#193

Post by WalterBright »

pron wrote: post #188
WalterBright wrote: post #175

Earlier quoted context omitted.

> Various compile-time evaluations are not even remotely positioned in D, Nim, or C++ as they are in Zig. See my other reply. I don't understand your comment. https://news.ycombinator.com/item?id=43748490

The revolution in Zig isn't in what the comptime mechanism is able to do, but how it allows the language to not have other features, which is what gives that language its power to simplicity ratio. Let me put it like this: Zig's comptime is a general compilation time computation mechanism that has introspection capabilities and replaces generics/templates, interfaces/typeclasses, macros, and conditional compilation.…

The example of a comptime parameter to a function is a template, whether you call it that or not :-/ A function template is a function with compile time parameters.

The irony here is back in the 2000's, many programmers were put off by C++ templates, and found them to be confusing. Myself included. But when I (belatedly) realized that function templates were functions with compile time parameters, I had an epiphany:

Don't call them templates! Call them functions with compile time parameters. The people who were confused by templates understood that immediately. Then later, after realizing that they had been using templates all along, became comfortable with templates.

BTW, I wholeheartedly agree that it is better to have a small set of features that can do the same thing as a larger set of features. But I'm not seeing how comptime is accomplishing that.

Re: Things Zig comptime won't do

#194

Post by pron »

WalterBright wrote: post #193
pron wrote: post #188

Earlier quoted context omitted.

The revolution in Zig isn't in what the comptime mechanism is able to do, but how it allows the language to not have other features, which is what gives that language its power to simplicity ratio. Let me put it like this: Zig's comptime is a general compilation time computation mechanism that has introspection capabilities and replaces generics/templates, interfaces/typeclasses, macros, and conditional compilation.…

The example of a comptime parameter to a function is a template, whether you call it that or not :-/ A function template is a function with compile time parameters. The irony here is back in the 2000's, many programmers were put off by C++ templates, and found them to be confusing. Myself included. But when I (belatedly) realized that function templates were functions with compile time parameters, I had an epiphany:…

> But I'm not seeing how comptime is accomplishing that.

Because Zig does the work of C++'s templates, macros, conditional compilation, constexprs, and concepts with one relatively simple feature.

Re: Things Zig comptime won't do

#195

Post by pcwalton »

matklad wrote: post #192
pcwalton wrote: post #187

Earlier quoted context omitted.

When we're responding to quite valid points about other languages having essentially the same features as Zig with subjective claims about ergonomics, the idea that Zig comptime is "revolutionary" is looking awfully flimsy. I agree with Walter: Zig isn't doing anything novel. Picking some features while leaving others out is something that every language does; if doing that is enough to make a language "revolutionary…

>for Zig enthusiasts, the set of features that Zig has appeals to them. Just like enthusiasts of every programming language. I find it rather amusing that it's a Java and a Rust enthusiast who are extolling Zig approach here! I am not particularly well read with respect to programming languages, but I don't recall many languages which define generic pair as fn Pair(A: type, B: type) type { return struct { fst: A, snd…

Well, if you strip away the curly braces and return statement, that's just a regular type definition. Modeling generic types as functions from types to types is just System F, which goes back to 1975. Turing-complete type-level programming is common in tons of languages, from TypeScript to Scala to Haskell.

I think the innovation here is imperative type-level programming--languages that support type-level programming are typically functional languages, or functional languages at the type level. Certainly interesting, but not revolutionary IMO.

Re: Things Zig comptime won't do

#196

Post by WalterBright »

matklad wrote: post #192
pcwalton wrote: post #187

Earlier quoted context omitted.

When we're responding to quite valid points about other languages having essentially the same features as Zig with subjective claims about ergonomics, the idea that Zig comptime is "revolutionary" is looking awfully flimsy. I agree with Walter: Zig isn't doing anything novel. Picking some features while leaving others out is something that every language does; if doing that is enough to make a language "revolutionary…

>for Zig enthusiasts, the set of features that Zig has appeals to them. Just like enthusiasts of every programming language. I find it rather amusing that it's a Java and a Rust enthusiast who are extolling Zig approach here! I am not particularly well read with respect to programming languages, but I don't recall many languages which define generic pair as fn Pair(A: type, B: type) type { return struct { fst: A, snd…

I might be misunderstanding something, but this is how it works in D:

    struct Pair(A, B) { A fst; B snd; }

    Pair!(int, float) p; // declaration of p as instance of Pair
It's just a struct with the addition of type parameters.

Re: Things Zig comptime won't do

#197

Post by pcwalton »

pron wrote: post #189
pcwalton wrote: post #187

Earlier quoted context omitted.

When we're responding to quite valid points about other languages having essentially the same features as Zig with subjective claims about ergonomics, the idea that Zig comptime is "revolutionary" is looking awfully flimsy. I agree with Walter: Zig isn't doing anything novel. Picking some features while leaving others out is something that every language does; if doing that is enough to make a language "revolutionary…

I'm sorry, but not being able to see that a design that uses a touchscreen to eliminate the keyboard is novel despite the touchscreen itself having been used elsewhere alongside a keyboard, shows a misunderstanding of what design is. Show me the language that used a general purpose compile-time mechanisms to avoid specialised features such as generics/templates, interfaces/typeclasses, macros, and conditional compila…

But Zig's comptime only approximates the features you mentioned; it doesn't fully implement them. Which is what the original article is saying. To use your analogy, using a touchscreen to eliminate a keyboard isn't very impressive if your touchscreen keyboard is missing keys.

If you say that incomplete implementations count, then I could argue that the C preprocessor subsumes generics/templates, interfaces/typeclasses†, macros, and conditional compilation.

†Exercise for the reader: build a generics system in the C preprocessor that #error's out if the wrong type is passed using the trick in [1].

[1]: https://stackoverflow.com/a/45450646

Re: Things Zig comptime won't do

#198

Post by WJW »

bibanez wrote: post #158
tines wrote: post #92

Earlier quoted context omitted.

A mobius strip does!

A mobius strip made out of paper has 2 sides, the usual one and the edge.

How about things like Klein bottles that have no edges? (Although I guess that unlike a Mobius strip it's not possible to make a real one here on Earth so the quote from OP still holds)

Re: Things Zig comptime won't do

#199

Post by matklad »

pcwalton wrote: post #195
matklad wrote: post #192

Earlier quoted context omitted.

>for Zig enthusiasts, the set of features that Zig has appeals to them. Just like enthusiasts of every programming language. I find it rather amusing that it's a Java and a Rust enthusiast who are extolling Zig approach here! I am not particularly well read with respect to programming languages, but I don't recall many languages which define generic pair as fn Pair(A: type, B: type) type { return struct { fst: A, snd…

Well, if you strip away the curly braces and return statement, that's just a regular type definition. Modeling generic types as functions from types to types is just System F, which goes back to 1975. Turing-complete type-level programming is common in tons of languages, from TypeScript to Scala to Haskell. I think the innovation here is imperative type-level programming--languages that support type-level programming…

The thing is, this is not type-level programming, this is term-level programming. That there's no separate language of types is the feature. Functional/imperative is orthogonal. You can imagine functional Zig which writes

    Pair :: type -> type -> type
    let Pair a b = product a b
This is one half of the innovation, dependent-types lite.

The second half is how every other major feature is expressed _directly_ via comptime/partial evaluation, not even syntax sugar is necessary. Generic, macros, and conditional compilation are the three big ones.

Re: Things Zig comptime won't do

#200

Post by WalterBright »

pron wrote: post #194
WalterBright wrote: post #193

Earlier quoted context omitted.

The example of a comptime parameter to a function is a template, whether you call it that or not :-/ A function template is a function with compile time parameters. The irony here is back in the 2000's, many programmers were put off by C++ templates, and found them to be confusing. Myself included. But when I (belatedly) realized that function templates were functions with compile time parameters, I had an epiphany:…

> But I'm not seeing how comptime is accomplishing that. Because Zig does the work of C++'s templates, macros, conditional compilation, constexprs, and concepts with one relatively simple feature.

From the article:

    fn print(comptime T: type, value: T) void {
That's a template. In D it looks like:

    void print(T)(T value) {
which is also a template.
Post reply on HN