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

171–180 of 252 posts

Re: Things Zig comptime won't do

#171

Post by bunderbunder »

Zig has a completely different feature, partial evaluation/specialization, which, none the less, is enough to cover most of use-cases for dynamic code generation.

These kinds of insights are what I love about Zig. Andrew Kelley just might be the patron saint of the KISS principle.

A long time ago I had an enlightenment experience where I was doing something clever with macros in F#, and it wasn't until I had more-or-less finished the whole thing that I realized I could implement it in a lot less (and more readable) code by doing some really basic stuff with partial application and higher order functions. And it would still be performant because the compiler would take care of the clever bits for me.

Not too long after that, macros largely disappeared from my Lisp code, too.

Re: Things Zig comptime won't do

#172

Post by naasking »

WalterBright wrote: post #124
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…

The partial evaluation/specialization is accomplished in D using a template. The example from the link: fn f(comptime x: u32, y: u32) u32 { if (x == 0) return y + 1; if (x == 1) return y * 2; return y; } and in D: uint f(uint x)(uint y) { if (x == 0) return y + 1; if (x == 1) return y * 2; return y; } The two parameter lists make it a function template, the first set of parameters are the template parameters, which a…

Using a different type vs. a different syntax can be an important usability consideration, particularly since D also has templates and other features, where Zig provides only the comptime type for all of them. Homogeneity can also be a nice usability win, though there are downsides as well.

Re: Things Zig comptime won't do

#173

Post by pron »

User23 wrote: post #33
pron wrote: post #18

Yes! To me, the uniqueness of Zig's comptime is a combination of two things: 1. comtpime replaces many other features that would be specialised in other languages with or without rich compile-time (or runtime) metaprogramming, and 2. comptime is referentially transparent [1], that makes it strictly "weaker" than AST macros, but simpler to understand; what's surprising is just how capable you can be with a comptime me…

Has anyone grafted Zig style macros into Common Lisp?

That wouldn't be very meaningful. The semantics of Zig's comptime is more like that of subroutines in a dynamic language - say, JavaScript functions - than that of macros. The point is that it's executed, and yields errors, at a different phase, i.e. compile time.

Re: Things Zig comptime won't do

#174

Post by pron »

keybored wrote: post #164
pron wrote: post #161

Earlier quoted context omitted.

My "manic praise" extends to the novelty of the feature as Zig's design is revolutionary. It is exciting because it's very rare to see completely novel designs in programming languages, especially in a language that is both easy to learn and intended for low-level programming. I wait 10-15 years before judging if a feature is "good"; determining that a feature is bad is usually quicker. > With comptime types, accordi…

> But the point is that all that is done at compile time, which is also the time when all more specialised features are checked. > ... > Again, everything is checked at compile-time. Once it compiles it will work just like generics. No. My compile-time when using a library with a comptime type in Zig is not guaranteed to work because my user experience could depend on if the library writer tested with the types (or c…

> No. My compile-time when using a library with a comptime type in Zig is not guaranteed to work because my user experience could depend on if the library writer tested with the types (or compile-time input) that I am using.[1] That’s not a problem in Java or Haskell: if the library works for Mary it will work for John no matter what the type-inputs are.

What you're saying isn't very meaningful. Even generics may impose restrictions on their type parameters (e.g. typeclasses in Zig or type bounds in Java) and don't necessarily work for all types. In both cases you know at compile-time whether your types fit the bounds or not.

It is true that the restrictions in Haskell/Java are more declarative, but the distinction is more a matter of personal aesthetic preference, which is exactly what's expressed in that blog post (although comptime is about as different from C++ templates as it is from Haskell/Java generics). Like anything, and especially truly novel approaches, it's not for everyone's tastes, but neither are Java, Haskell, or Rust, for that matter. That doesn't make Zig's approach any less novel or interesting, even if you don't like it. I find Rust's design unpalatable, but that doesn't mean it's not interesting or impressive, and Zig's approach -- again, like it or not -- is even more novel.

Re: Things Zig comptime won't do

#175

Post by WalterBright »

pron wrote: post #162
WalterBright wrote: post #95

Earlier quoted context omitted.

It's not novel. D pioneered compile time function execution (CTFE) back around 2007. The idea has since been adopted in many other languages, like C++. One thing it is used for is generating string literals, which then can be fed to the compiler. This takes the place of macros. CTFE is one of D's most popular and loved features.

It is novel to the point of being revolutionary. As I wrote in my comment, "the novelty isn't in the feature itself, but in the place it has in the language". It's one thing to come up with a feature. It's a whole other thing to position it within the language. Various compile-time evaluations are not even remotely positioned in D, Nim, or C++ as they are in Zig. The point of Zig's comptime is not that it allows you…

> 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

Re: Things Zig comptime won't do

#176

Post by WalterBright »

msteffen wrote: post #167
WalterBright wrote: post #124

Earlier quoted context omitted.

The partial evaluation/specialization is accomplished in D using a template. The example from the link: fn f(comptime x: u32, y: u32) u32 { if (x == 0) return y + 1; if (x == 1) return y * 2; return y; } and in D: uint f(uint x)(uint y) { if (x == 0) return y + 1; if (x == 1) return y * 2; return y; } The two parameter lists make it a function template, the first set of parameters are the template parameters, which a…

Here is, I think, an interesting example of the kind of thing TFA is talking about. In case you’re not already familiar, there’s an issue that game devs sometimes struggle with, where, in C/C++, an array of structs (AoS) has a nice syntactic representation in the language and is easy to work with/avoid leaks, but a struct of arrays (SoA) has a more compact layout in memory and better performance. Zig has a library to…

D doesn't have a macro system, either, so I don't understand what you mean.

Re: Things Zig comptime won't do

#177

Post by panzi »

jenadine wrote: post #131
panzi wrote: post #91

Earlier quoted context omitted.

> Personally, I find the idea that a compiler might be able to reach outside itself completely terrifying (Access the network or a database? Are you nuts?). Yeah, although so can build.rs or whatever you call in your Makefile. If something like cargo would have built-in sandboxing, that would be interesting.

You can run cargo in a sandbox.

Yeah, but I want cargo to do that for me. And tell me if any build.rs does something it shouldn't.

Re: Things Zig comptime won't do

#178

Post by WalterBright »

naasking wrote: post #172
WalterBright wrote: post #124

Earlier quoted context omitted.

The partial evaluation/specialization is accomplished in D using a template. The example from the link: fn f(comptime x: u32, y: u32) u32 { if (x == 0) return y + 1; if (x == 1) return y * 2; return y; } and in D: uint f(uint x)(uint y) { if (x == 0) return y + 1; if (x == 1) return y * 2; return y; } The two parameter lists make it a function template, the first set of parameters are the template parameters, which a…

Using a different type vs. a different syntax can be an important usability consideration, particularly since D also has templates and other features, where Zig provides only the comptime type for all of them. Homogeneity can also be a nice usability win, though there are downsides as well.

Zig's use of comptime in a function argument makes it a template :-/

I bet if you use such a function with different comptime arguments, compile it, and dump the assembler you'll see that function appearing multiple times, each with somewhat different code generated for it.

Re: Things Zig comptime won't do

#179

Post by WalterBright »

Someone wrote: post #144
WalterBright wrote: post #95

Earlier quoted context omitted.

It's not novel. D pioneered compile time function execution (CTFE) back around 2007. The idea has since been adopted in many other languages, like C++. One thing it is used for is generating string literals, which then can be fed to the compiler. This takes the place of macros. CTFE is one of D's most popular and loved features.

> D pioneered compile time function execution (CTFE) back around 2007 Pioneered? Forth had that in the 1970s, lisp somewhere in the 1960s (I’m not sure whether the first versions of either had it, so I won’t say 1970 respectively 1960), and there may be other or even older examples.

True, but consider that Forth and Lisp started out as interpreted languages, meaning the whole thing can be done at compile time. I haven't seen this feature before in a language that was designed to be compiled to machine code, such as C, Pascal, Fortran, etc.

BTW, D's ImportC C compiler does CTFE, too!! CTFE is a natural fit for C, and works like a champ. Standard C should embrace it.

Re: Things Zig comptime won't do

#180

Post by naasking »

WalterBright wrote: post #178
naasking wrote: post #172

Earlier quoted context omitted.

Using a different type vs. a different syntax can be an important usability consideration, particularly since D also has templates and other features, where Zig provides only the comptime type for all of them. Homogeneity can also be a nice usability win, though there are downsides as well.

Zig's use of comptime in a function argument makes it a template :-/ I bet if you use such a function with different comptime arguments, compile it, and dump the assembler you'll see that function appearing multiple times, each with somewhat different code generated for it.

> 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.

Post reply on HN