They are awesome but they make compile-time arbitrarily bad. The D compiler is roughly as fast as the Go one. However, D has macros though and that makes it very slow to compile sometimes.
The alternative to macros are code generators. Works fine for bigger stuff like a parser generator but not for smaller stuff like a regex.
It's possible that Zig's approach helps here -- since the metalanguage is just the language, you can take some of your intuition about performance along to compile time. And the macro language is not weirdly restricted, so you can write something you're more used to, with similar idioms.
In the limit this is clear: I'm using several Python code generators C++ in https://www.oilshell.org, and it's easy to reason about the performance of Python. Doing the same in C++ metaprogramming would almost certainly be a lot slower. It would also give me less indication of code bloat; right now I simply count the lines of output to test whether my code generator is "reasonable".
e.g. I generate ~90K lines of code now, which is reasonable, but if I had 1M or 10M lines of code, that wouldn't be. But there's not that much of a sanity check on macros (except binary size).
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-...
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.
The question is whether you do the meta programming/code generation within the language or as external tool. Code bloat is an issue in both cases.
Macros make it easy to write code which generates code which generates code which... This enables some wonderful use cases, often around generating type declarations. If done with an isomorphic language, you can also reuse the same code for compile time and runtime implementations with just thin wrappers.
External code generators however will build faster because the build system takes care of reusing the intermediate code.
Not according to this benchmark:
https://github.com/nordlow/compiler-benchmark
dmd performed around 1.5x to 4x faster than go.