News for hackers. Stuff that matters.
Re:Dave Herman’s contributions to Rust by pcwalton on Monday May 03, 2021 @04:35PM (#27030304)
Macros and compile-time function evaluation are different and fill different roles. Macros define new syntax, while compile-time function evaluation evaluates expressions written using the existing syntax. The corresponding Rust feature for the latter is not macros, but rather "const fn".
Re:Dave Herman’s contributions to Rust by chubot on Tuesday May 04, 2021 @02:44AM (#27034674)
I think they both have potential performance issues in the compiler though, and both can be compared with textual code generation.

I think of one as metaprogramming with the parser and the other as metaprogramming with an interpreter. (And the C preprocessor is metaprogramming with only a lexer. Code generation is the kind of metaprogramming that every language supports :) )

Although maybe you're saying Zig doesn't have the functionality of Rust macros, and that could be true; I haven't played with it enough.

However I do think there is overlap as Zig implements printf with compile-time evaluation and Rust does it with macros:

https://ziglang.org/documentation/master/#Case-Study-printf-...

https://andrewkelley.me/post/zig-programming-language-blurs-...

Re:Dave Herman’s contributions to Rust by AndyKelley on Tuesday May 04, 2021 @01:16PM (#27039936)
In zig you get a compile error if you exceed 1000 backwards branches (e.g. a loop or a function call). If you want to raise the quota you bump it with e.g. `@setEvalBranchQuota(2000);`. This is how we solve the halting problem :)

Anyway if you want to know why your compile time is slow in a given zig project, you can probably get pretty far by grepping for calls to that builtin.