In other words, there is a capability here that Nim really, really wants, and that Zig really, really doesn't want, so on that front they are not competing in their designs.
In other words, there is a capability here that Nim really, really wants, and that Zig really, really doesn't want, so on that front they are not competing in their designs.
I also take issue with your statement that zig is "more minimal" since that only applies to the user's perspective -- from the compiler's perspective, macros make a language far more minimal. But i vaguely recall already discussing this distinction with you so i don't want to rehash it.
At any rate i will definitely be paying attention to andrew's progress, he has a really clear vision.
Macros are controversial. I love them in Scheme and Clojure, but I wouldn't want them in any language aimed at a larger, more mainstream crowd. At the very least, macros introduce another meta-language to know (and if they're in a language with a complex type-level language like Rust or Haskell then they're a third language within the language), but I think it's a matter of personal aesthetic preference.
> But i vaguely recall already discussing this distinction with you so i don't want to rehash it.
Maybe we did. :)
See my comment here about "Zig' ": https://news.ycombinator.com/item?id=24293611
Perhaps now you see what I meant when I said that Zig's simplicity hides its radical design.
You can also do `const a = static(foo(x, y, z))` to force normal function to be evaluated at compile-time and store them in a constants.
Hence you don't need to use macros for compile-time evaluation in Nim just like in Zig. However macros are necessary for AST manipulation.