4 ms·
(I wanted to read your [1] reference but you seem to have forgotten to add it.) I agree that comptime is not the same thing as Rust macros, I mostly mentioned
by simias 6y ago
(I wanted to read your [1] reference but you seem to have forgotten to add it.)
I agree that comptime is not the same thing as Rust macros, I mostly mentioned Rust macros because I felt it was a gotcha to my argument since my criticisms of Zig's comptime could be levied at Rust's macros.
To be a little more specific in my criticism, the fact that Zig implements generics with comptime is a bit of a red flag for me. I worry, perhaps unreasonably, that it's going to lead to fragmentation in the way generics are handled in various libraries, leading to headaches and incompatibilities. It is a smart solution, but I wonder if it's a pragmatical solution.
It's definitely an interesting approach at any rate, it's great to see all this creativity in systems language. I don't want to sound too critical of Zig, it's a cool language.
- pron 6y agoOops, sorry. I meant that macros are referentially opaque, and therefore strictly more expressive than comptime: https://news.ycombinator.com/item?id=26375027 https://news.ycombinator.com/item?id=26375027 > my criticisms of Zig's comptime could be levied at Rust's macros. Except that comptime is nothing at all like macros, even though, as it turns out, it can replace enough of their use to make them unnecessary in low-level languages. > I worry, perhaps unreasonably, that it's going to lead to fragmentation in the way generics are handled in various libraries, leading to headaches and incompatibilities. But generics in Zig are just functions, and so the problem should be no better but no worse than any API. comptime is drastically less "crazy" or "weird" or hard to make compatible than macros, which Zig doesn't have at all.