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

161–170 of 252 posts

Re: Things Zig comptime won't do

#161

Post by pron »

keybored wrote: post #94
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…

I’ve never managed to understand your year-long[1] manic praise over this feature. Given that you’re a language implementer. It’s very cool to be able to just say “Y is just X”. You know in a museum. Or at a distance. Not necessarily as something you have to work with daily. Because I would rather take something ranging from Java’s interface to Haskell’s typeclasses since once implemented, they’ll just work. With com…

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, according to what I’ve read, you’ll have to bring your T to the comptime and find out right then and there if it will work. Without enough foresight it might not.

But the point is that all that is done at compile time, which is also the time when all more specialised features are checked.

> That’s not something I want. I just want generics or parametric polymorphism or whatever it is to work once it compiles.

Again, everything is checked at compile-time. Once it compiles it will work just like generics.

> I mean just let me use the language declaratively.

That's fine and expected. I believe that most language preferences are aesthetic, and there have been few objective reasons to prefer some designs over others, and usually it's a matter of personal preference or "extra-linguistic" concerns, such as availability of developers and libraries, maturity, etc..

> Now I’m not so sure?

Personally, I wouldn't dream of using Zig or Rust for important software because they're so unproven. But I do find novel designs fascinating. Some even match my own aesthetic preferences.

Re: Things Zig comptime won't do

#162

Post by pron »

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

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 to do certain computations at compile-time, but that it replaces more specialised features such as templates/generics, interfaces, macros, and conditional compilation. That creates a completely novel simplicity/power balance.

If the presence of features is how we judge design, then the product with the most features would be considered the best design. Of course, often the opposite is the case. The absence of features is just as crucial for design as their presence. It's like saying that a device with a touchscreen and a physical keyboard has essentially the same properties as a device with only a touchscreen.

If a language has a mechanism that can do exactly what Zig's comptime does but it also has generics or templates, macros, and/or conditional compilation, then it doesn't have anything resembling Zig's comptime.

Re: Things Zig comptime won't do

#163

Post by User23 »

dokyun wrote: post #116
TinkersW wrote: post #107

Earlier quoted context omitted.

Lisp is so powerful, but without static types you can't even do basic stuff like overloading, and have to invent a way to even check the type(for custom types) so you can branch on type.

> Lisp is so powerful, but . You use defmethod for overloading. Types check themselves.

And a modern compiler will jmp past the type checks if the inferencer OKs it!

Re: Things Zig comptime won't do

#164

Post by keybored »

pron wrote: post #161
keybored wrote: post #94

Earlier quoted context omitted.

I’ve never managed to understand your year-long[1] manic praise over this feature. Given that you’re a language implementer. It’s very cool to be able to just say “Y is just X”. You know in a museum. Or at a distance. Not necessarily as something you have to work with daily. Because I would rather take something ranging from Java’s interface to Haskell’s typeclasses since once implemented, they’ll just work. With com…

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

> That's fine and expected. I believe that most language preferences are aesthetic, and there have been few objective reasons to prefer some designs over others, and usually it's a matter of personal preference or "extra-linguistic" concerns, such as availability of developers and libraries, maturity, etc..

Please don’t retreat to aesthetics. What I brought up is a concrete and objective user experience tradeoff.

[1] based on https://strongly-typed-thoughts.net/blog/zig-2025#comptime-i...

Re: Things Zig comptime won't do

#165

Post by keybored »

throwawaymaths wrote: post #151
keybored wrote: post #145

Earlier quoted context omitted.

comptime can’t outright replace many language features because it chooses different tradeoffs to get to where it wants. You get a “one thing to rule all” at the expense of less declarative use. Which I already said in my original comment. But here’s a source that I didn’t find last time: https://strongly-typed-thoughts.net/blog/zig-2025#comptime-i... Academics have thought about evaluating things at compile time (or…

> comptime can’t outright replace many language features because it chooses different tradeoffs to get to where it wants. You're missing the point. I don't have any theory to qualify this, but: I've worked in a language with lisp-ey macros, and I absolutely hate hate hate when people build too-clever DSLs that hide a lot of weird shit like creating variable names or pluralizing database tables for me, swapping camel-…

No, you are clearly missing the point because I laid out concrete critiques about how Zig doesn’t replace certain concrete language features with One Thing to Rule Them All. All in reply to someone complimenting Zig on that same subject.

That you want to make a completely different point about macros gone wild is not my problem.

Re: Things Zig comptime won't do

#166

Post by keybored »

keybored wrote: post #94
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…

I’ve never managed to understand your year-long[1] manic praise over this feature. Given that you’re a language implementer. It’s very cool to be able to just say “Y is just X”. You know in a museum. Or at a distance. Not necessarily as something you have to work with daily. Because I would rather take something ranging from Java’s interface to Haskell’s typeclasses since once implemented, they’ll just work. With com…

> Because I would rather take something ranging from Java’s interface to Haskell’s typeclasses since once implemented, they’ll just work. With comptime types, according to what I’ve read, you’ll have to bring your T to the comptime and find out right then and there if it will work. Without enough foresight it might not.

This was perhaps a bad comparison and I should have compared e.g. Java generics to Zig’s comptime T.

Re: Things Zig comptime won't do

#167

Post by msteffen »

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…

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 that allows you to have an AoS that is laid out in memory like a SoA: https://zig.news/kristoff/struct-of-arrays-soa-in-zig-easy-i... . If you read the implementation (https://github.com/ziglang/zig/blob/master/lib/std/multi_arr...) the SoA is an elaborately specialized type, parameterized on a struct type that it introspects at compile time.

It’s neat because one might reach for macros for this sort of the thing (and I’d expect the implementation to be quite complex, if it’s even possible) but the details of Zig’s comptime—you can inspect the fields of the type parameter struct, and the SoA can be highly flexible about its own fields—mean that you don’t need a macro system, and the Zig implementation is actually simpler than a macro approach probably would be.

Re: Things Zig comptime won't do

#168

Post by pklausler »

pjmlp wrote: post #138
chongli wrote: post #137

Earlier quoted context omitted.

languages have to come in curly brackets for adoption Python and Ruby are two very popular counterexamples.

Not really, Ruby has plenty of curly brackets, e.g. 5.times { puts "hello!" }. In both cases, while it wasn't curly brackets that drove their adoption, it was unavoidable frameworks. Most people only use Ruby when they have Rails projects, and what made Python originally interesting was Zope CMS. And nowadays AI/ML frameworks, that are actually written in C, C++ and Fortran, making Python relevant because scientists…

Which AI/ML frameworks are written in Fortran?

Re: Things Zig comptime won't do

#170

Post by pjmlp »

pklausler wrote: post #168
pjmlp wrote: post #138

Earlier quoted context omitted.

Not really, Ruby has plenty of curly brackets, e.g. 5.times { puts "hello!" }. In both cases, while it wasn't curly brackets that drove their adoption, it was unavoidable frameworks. Most people only use Ruby when they have Rails projects, and what made Python originally interesting was Zope CMS. And nowadays AI/ML frameworks, that are actually written in C, C++ and Fortran, making Python relevant because scientists…

Which AI/ML frameworks are written in Fortran?

Probably none, it was more a kind of expression, given the tradition of "Python" libraries, that are actually bindings to C, C++, Fortran libraries.
Post reply on HN