2 ms·

A single construct does the work, or most of the work, of generics, value generics, const fn, traits, attributes (although I expect some form of attributes migh

by pron 7y ago

A single construct does the work, or most of the work, of generics, value generics, const fn, traits, attributes (although I expect some form of attributes might be added to Zig) and macros, and it does so without type-level programming or macro-level programming, both their own mini-languages. A kludge is in the eye of the beholder, but one is simpler than five or six.

zozbot234 7y ago
Rust has procedural macros too. And they're not a separate "mini-language" like the C++ template hacks, they just use Rust itself, except with a phase separation involved since they run at compile time.
- pjmlp 7y ago
  In C++17 and moreso in C++20, doing C++ template hacks is only excusable for legacy code, or trying to make code portable to older compilers.
- pron 7y ago
  This is worse. Feature-rich languages like C++ and Rust always end up adopting pretty much every nice feature from every other language. The trick is to have fewer features, not more; at least that's my aesthetic preference. In other words, brag about the features you don't have, not the features you do :)
- jeltz 7y ago
  As someone who is using procedural macros in my crates: they are nowhere close to as powerful yet as Zig's compile time evaluation. For example they cannot be used in expressions in stable Rust without ugly hacks yet, and the tools for generating the new AST are quite clunky and hard to write fast code for.
Rusky 7y ago
That's hardly an honest comparison. I can just as easily split comptime into "type comptime," "value comptime," "comptime blocks," "builtin functions like @isInteger," and "inline control structures" (that one doesn't even use the "comptime" name!). Arguably this combination is more complex than Rust's. It has no way to constrain a comptime type argument (traits), so you get error messages like C++ templates. It has no way to constrain a function to be comptime-compatible (const fn), so you get more error messages like C++ templates. When you want to combine things, you manage phase ordering and idioms by hand, basically re-implementing Rust-like concepts at every use site. Sometimes one or two more concepts in the language makes things simpler. To use a subject you've discussed before, it's similar to scoped continuations vs full call/cc.
- pron 7y ago
  > I can just as easily split comptime into In Rust, generics, macros, traits, compile-time evaluation are different constructs with drastically different syntax (and generics and value generics are different features, implemented at different times, but I can accept them as a single construct). > It has no way to constrain a comptime type argument (traits) It does: introspection, just as Clojure can constrain arguments, only Zig does it at compile time. > so you get error messages like C++ templates You don't because in C++ templates are programmed in their own sub-language with SFINAE tricks (at least in the C++ versions I use; they've probably added new ways to do this, as they do). In Zig, it's just Zig computation. You'd get similar compile-time errors as you would get, at runtime, in, say, Clojure or Python. > When you want to combine things, you manage phase ordering and idioms by hand, basically re-implementing Rust-like concepts at every use site. You don't need to reimplement things by hand at every use site; you just call a subroutine at compile time. > Sometimes one or two more concepts in the language makes things simpler. I agree, but I think that Zig's comptime brings revolutionary simplicity to the very complex subject of partial evaluation which is so important in systems languages. How well it would work in practice remains to be seen, and I may well be disappointed, but I find Zig's approach of simplicity first very appealing. I agree it's a matter of taste.
  - Rusky 7y ago
    > ... generics, traits ... Again, these are just as much a single feature as Zig comptime. Traits are like comptime types, or else (closer to what Zig does) comptime type variable introspection. > You'd get similar compile-time errors as you would get, at runtime, in, say, Clojure or Python. Exactly- you're not writing plain Zig, you're writing a Zig-adjacent dynamically typed language with new ways to do almost everything and different tradeoffs around correctness. > just call a subroutine at compile time. Whoever wrote that subroutine did the reimplementation by hand.
    - pron 7y ago
      You're looking at this differently from me. The way I see it, Zig is not, say, C, with an extra compile-time language to replace macros. It's a simple dynamic language, with optional typing, where you select which code runs at compile time and which runs at runtime. Aside from being quite revolutionary in that respect (precisely because the compile-time code doesn't operate on the AST, like in Lisp, but on program objects) -- languages like Nim and Zig have a similar feature, but they also have other features -- it has certain big practical implications. For one, you could imagine stepping through a Zig program with a debugger at compile-time, seeing how it operates on Zig objects, not produces an AST that goes through another stage. For another, in terms of program semantics and analysis, the program means the same thing as if the language were truly dynamic and everything was evaluated at runtime. I.e. Zig has the semantics of a very simple dynamic language. So the subroutines that run at compile time and that you or someone else writes, are just simple Zig code you can read (and maybe, some day, step through).

by pron 7y ago

zozbot234 7y ago

Rust has procedural macros too. And they're not a separate "mini-language" like the C++ template hacks, they just use Rust itself, except with a phase separation involved since they run at compile time.

pjmlp 7y ago
In C++17 and moreso in C++20, doing C++ template hacks is only excusable for legacy code, or trying to make code portable to older compilers.
pron 7y ago
This is worse. Feature-rich languages like C++ and Rust always end up adopting pretty much every nice feature from every other language. The trick is to have fewer features, not more; at least that's my aesthetic preference. In other words, brag about the features you don't have, not the features you do :)
jeltz 7y ago
As someone who is using procedural macros in my crates: they are nowhere close to as powerful yet as Zig's compile time evaluation. For example they cannot be used in expressions in stable Rust without ugly hacks yet, and the tools for generating the new AST are quite clunky and hard to write fast code for.

Rusky 7y ago

That's hardly an honest comparison. I can just as easily split comptime into "type comptime," "value comptime," "comptime blocks," "builtin functions like @isInteger," and "inline control structures" (that one doesn't even use the "comptime" name!). Arguably this combination is more complex than Rust's. It has no way to constrain a comptime type argument (traits), so you get error messages like C++ templates. It has no way to constrain a function to be comptime-compatible (const fn), so you get more error messages like C++ templates. When you want to combine things, you manage phase ordering and idioms by hand, basically re-implementing Rust-like concepts at every use site. Sometimes one or two more concepts in the language makes things simpler. To use a subject you've discussed before, it's similar to scoped continuations vs full call/cc.

pron 7y ago
> I can just as easily split comptime into In Rust, generics, macros, traits, compile-time evaluation are different constructs with drastically different syntax (and generics and value generics are different features, implemented at different times, but I can accept them as a single construct). > It has no way to constrain a comptime type argument (traits) It does: introspection, just as Clojure can constrain arguments, only Zig does it at compile time. > so you get error messages like C++ templates You don't because in C++ templates are programmed in their own sub-language with SFINAE tricks (at least in the C++ versions I use; they've probably added new ways to do this, as they do). In Zig, it's just Zig computation. You'd get similar compile-time errors as you would get, at runtime, in, say, Clojure or Python. > When you want to combine things, you manage phase ordering and idioms by hand, basically re-implementing Rust-like concepts at every use site. You don't need to reimplement things by hand at every use site; you just call a subroutine at compile time. > Sometimes one or two more concepts in the language makes things simpler. I agree, but I think that Zig's comptime brings revolutionary simplicity to the very complex subject of partial evaluation which is so important in systems languages. How well it would work in practice remains to be seen, and I may well be disappointed, but I find Zig's approach of simplicity first very appealing. I agree it's a matter of taste.
- Rusky 7y ago
  > ... generics, traits ... Again, these are just as much a single feature as Zig comptime. Traits are like comptime types, or else (closer to what Zig does) comptime type variable introspection. > You'd get similar compile-time errors as you would get, at runtime, in, say, Clojure or Python. Exactly- you're not writing plain Zig, you're writing a Zig-adjacent dynamically typed language with new ways to do almost everything and different tradeoffs around correctness. > just call a subroutine at compile time. Whoever wrote that subroutine did the reimplementation by hand.
  - pron 7y ago
    You're looking at this differently from me. The way I see it, Zig is not, say, C, with an extra compile-time language to replace macros. It's a simple dynamic language, with optional typing, where you select which code runs at compile time and which runs at runtime. Aside from being quite revolutionary in that respect (precisely because the compile-time code doesn't operate on the AST, like in Lisp, but on program objects) -- languages like Nim and Zig have a similar feature, but they also have other features -- it has certain big practical implications. For one, you could imagine stepping through a Zig program with a debugger at compile-time, seeing how it operates on Zig objects, not produces an AST that goes through another stage. For another, in terms of program semantics and analysis, the program means the same thing as if the language were truly dynamic and everything was evaluated at runtime. I.e. Zig has the semantics of a very simple dynamic language. So the subroutines that run at compile time and that you or someone else writes, are just simple Zig code you can read (and maybe, some day, step through).