4 ms·

I admit that I'm a Rust fanboy so it probably wraps my view a bit, but from personal experience I don't consider unlimited compile-time code execution to be a c

by simias 6y ago

I admit that I'm a Rust fanboy so it probably wraps my view a bit, but from personal experience I don't consider unlimited compile-time code execution to be a completely good thing. Yes, it makes the language more approachable, yes it makes it easier for people who aren't familiar with the language to understand what's going on. That's nice, but that's not critically important IMO. It's nice if you want to impress people on HN, but if you use the language day-to-day you'll get over that stuff pretty quickly. On the other hand this type of extreme customization means that even for somebody very familiar with the language you still have to be on your toes because innocuous looking code could behave surprisingly due to comptime shenanigans. On the other hand languages with a more rigid structure may end up being more verbose but that leads to code that a proficient coder can unambiguously understand without having to mentally expand comptime blocks or macros. This is effectively the metaprogramming equivalent of the statically vs dynamically typed debate. Yes, dynamic code is easier to write but it can be harder to maintain and leads to worse compiler diagnostics and generally requires more unit tests to validate that it's doing the right thing. I think macros/comptime behave similarly when compared to stricter, more limited metaprograming like Rust's generics system. Rust has macros too of course, but they're a pain to write in my experience, and I'd almost argue that it's a feature. You only use them if you really have to, and after careful consideration, or at least that's how I use them.

jiofih 6y ago
Your points are in stark contrast to the reality of the article. The Rust code produced is the one you have to be “on your toes” with due to unnecessary complexity, while Zig, despite the compile time features, is completely straightforward to understand. Maybe a second reading is due.
- stevenhuang 6y ago
  Agreed. Of note is that the compile time features of Zig works towards Rust's goal of zero cost abstractions as well.
twic 6y ago
> On the other hand this type of extreme customization means that even for somebody very familiar with the language you still have to be on your toes because innocuous looking code could behave surprisingly due to comptime shenanigans. Could you give some concrete examples of this?
- lhorie 6y ago
  Only thing I can think of is something blowing up when cross-compiling to a different target because there's no code in the static if branch to handle that architecture (e.g. stdlib doesn't officially support WASI). But that's not really comptime's fault per se IMHO; you can break things in similar ways in golang, for example. Unlike C, zig's comptime doesn't have grammar altering abilities
pron 6y ago
Zig doesn't have unlimited compile-time execution and what it has is strictly weaker than Rust's macros [1]. Rather, it has one carefully designed construct that is both very simple and very expressive, and yet isn't as weird or as dangerous as macros. It is not "extreme customisation" but just the right amount to make the language both simple and expressive without extreme measures like macros. Zig accepts that macros are problematic, and shows how far you can go without them altogether. OTOH, while macros are common enough in Rust that while you may not write them yourself all the time, you do use them frequently. I guess that there is some small truth to your allusion to the static-vs-dynamic debate, but Zig does give you errors at compile-time, and elaborate things it can check at runtime are much easier to express than in Rust. But I would say that Rust is a language in a well-known tradition, and is clearly a "cleaned up C++", while Zig is something that we haven't seen before. It is not dynamic in the same sense as dynamic languages -- you get the checks done at compile-time -- but it is not part of the familiar tradition of typed languages or even any low-level language. I'm not a devout minimalist, but when it comes to low-level programming in particular, language simplicity is a very important feature, and before Zig it wasn't clear it was achievable at all in low-level languages without significantly compromising on expressivity and safety.
- smt1 6y ago
  I'd say Rust is much more like Ocaml (with very different memory management) than anything related to C++ (in fact, if you unlearn C++, or know any ML-ish language, idiomatic Rust becomes significantly easier). Ownership types are probably Rust's main difference relative to any systems language, I think the first attempt to bring it to a C-ish language is probably Verona: https://microsoft.github.io/verona/explore.html https://microsoft.github.io/verona/explore.html (though it's very immature)
  - pron 6y ago
    Let's say it's a love-child of ML and C++.
  - otabdeveloper4 6y ago
    C++ is closer to ML than to C.
lhorie 6y ago
I don't think comparing zig's comptime with rust macros is actually that apt of a comparison. I tend to think of rust macros as syntactic sugar. Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways. Top level const expressions are automatically comptime, modules are comptime structs, static polymorphism is used all over the stdlib (e.g. std.mem.eql), heck std.debug.print is written without special compiler tricks thanks to how cleanly you can use comptime in zig. I think the idea that zig is a very sharp knife is true, but the overlap of footguns and comptime is not as big as one would think (@fieldParentPtr mistakes comes to mind, but that's sort of about it)
- ifreund 6y ago
  The implementation of the pinned keyword proposed here should fix most if not all @fieldParentPtr() footguns https://github.com/ziglang/zig/issues/7769 https://github.com/ziglang/zig/issues/7769
- zozbot234 6y ago
  > Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways. TANSTAAFL. Compile-time evaluation cannot truly "permeate" a language because most practical languages preserve a phase distinction between compile time and runtime. (This phase distinction is somewhat softened, e.g. in interpreted languages as well as in advanced PL's which include such features as dependent types). For a system programming language like Rust which relies on this clear-cut phase separation, macros and proc macros (as well as `const`-marked expressions and functions) are ultimately more elegant.
  - deleted 6y ago
    [deleted]
chubot 6y ago
But isn't Rust basically getting constexpr from C++? I saw that in some recent release notes: https://lobste.rs/s/lng3c0/announcing_rust_1_50_0 https://lobste.rs/s/lng3c0/announcing_rust_1_50_0 constexpr is basically making more of C++ available at compile time -- e.g. lots of C++11, 14, 17, and 20 are just allowing more of the language at compile time. Including STL, allocators, etc. Zig simplifies everything by designing in comptime up front, rather than gradually opening it up with ad hoc rules over 10+ years. My understanding is that Rust is going down the same path as C++. So you're going to have 2 kinds of macros AND comptime-like/constexpr-like compile time execution.
- steveklabnik 6y ago
  Yes, something very similar to constexpr. > Zig simplifies everything by designing in comptime up front, rather than gradually opening it up with ad hoc rules over 10+ years. I am not 100% sure that I agree with these characterizations, personally, but they're both valid strategies for sure.
  - girvo 6y ago
    Regardless of the particular trade-offs the various languages under discussion are choosing to make, it’s exciting to me that more and more languages are adapting, exposing and using “compile time” systems

by simias 6y ago

jiofih 6y ago

Your points are in stark contrast to the reality of the article. The Rust code produced is the one you have to be “on your toes” with due to unnecessary complexity, while Zig, despite the compile time features, is completely straightforward to understand. Maybe a second reading is due.

stevenhuang 6y ago
Agreed. Of note is that the compile time features of Zig works towards Rust's goal of zero cost abstractions as well.

twic 6y ago

> On the other hand this type of extreme customization means that even for somebody very familiar with the language you still have to be on your toes because innocuous looking code could behave surprisingly due to comptime shenanigans. Could you give some concrete examples of this?

lhorie 6y ago
Only thing I can think of is something blowing up when cross-compiling to a different target because there's no code in the static if branch to handle that architecture (e.g. stdlib doesn't officially support WASI). But that's not really comptime's fault per se IMHO; you can break things in similar ways in golang, for example. Unlike C, zig's comptime doesn't have grammar altering abilities

pron 6y ago

Zig doesn't have unlimited compile-time execution and what it has is strictly weaker than Rust's macros [1]. Rather, it has one carefully designed construct that is both very simple and very expressive, and yet isn't as weird or as dangerous as macros. It is not "extreme customisation" but just the right amount to make the language both simple and expressive without extreme measures like macros. Zig accepts that macros are problematic, and shows how far you can go without them altogether. OTOH, while macros are common enough in Rust that while you may not write them yourself all the time, you do use them frequently. I guess that there is some small truth to your allusion to the static-vs-dynamic debate, but Zig does give you errors at compile-time, and elaborate things it can check at runtime are much easier to express than in Rust. But I would say that Rust is a language in a well-known tradition, and is clearly a "cleaned up C++", while Zig is something that we haven't seen before. It is not dynamic in the same sense as dynamic languages -- you get the checks done at compile-time -- but it is not part of the familiar tradition of typed languages or even any low-level language. I'm not a devout minimalist, but when it comes to low-level programming in particular, language simplicity is a very important feature, and before Zig it wasn't clear it was achievable at all in low-level languages without significantly compromising on expressivity and safety.

smt1 6y ago
I'd say Rust is much more like Ocaml (with very different memory management) than anything related to C++ (in fact, if you unlearn C++, or know any ML-ish language, idiomatic Rust becomes significantly easier). Ownership types are probably Rust's main difference relative to any systems language, I think the first attempt to bring it to a C-ish language is probably Verona: https://microsoft.github.io/verona/explore.html https://microsoft.github.io/verona/explore.html (though it's very immature)
- pron 6y ago
  Let's say it's a love-child of ML and C++.
- otabdeveloper4 6y ago
  C++ is closer to ML than to C.

lhorie 6y ago

I don't think comparing zig's comptime with rust macros is actually that apt of a comparison. I tend to think of rust macros as syntactic sugar. Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways. Top level const expressions are automatically comptime, modules are comptime structs, static polymorphism is used all over the stdlib (e.g. std.mem.eql), heck std.debug.print is written without special compiler tricks thanks to how cleanly you can use comptime in zig. I think the idea that zig is a very sharp knife is true, but the overlap of footguns and comptime is not as big as one would think (@fieldParentPtr mistakes comes to mind, but that's sort of about it)

ifreund 6y ago
The implementation of the pinned keyword proposed here should fix most if not all @fieldParentPtr() footguns https://github.com/ziglang/zig/issues/7769 https://github.com/ziglang/zig/issues/7769
zozbot234 6y ago
> Zig's comptime permeates the language thoroughly and in fundamental (and IMHO very pragmatic) ways. TANSTAAFL. Compile-time evaluation cannot truly "permeate" a language because most practical languages preserve a phase distinction between compile time and runtime. (This phase distinction is somewhat softened, e.g. in interpreted languages as well as in advanced PL's which include such features as dependent types). For a system programming language like Rust which relies on this clear-cut phase separation, macros and proc macros (as well as `const`-marked expressions and functions) are ultimately more elegant.
- deleted 6y ago
  [deleted]

chubot 6y ago

But isn't Rust basically getting constexpr from C++? I saw that in some recent release notes: https://lobste.rs/s/lng3c0/announcing_rust_1_50_0 https://lobste.rs/s/lng3c0/announcing_rust_1_50_0 constexpr is basically making more of C++ available at compile time -- e.g. lots of C++11, 14, 17, and 20 are just allowing more of the language at compile time. Including STL, allocators, etc. Zig simplifies everything by designing in comptime up front, rather than gradually opening it up with ad hoc rules over 10+ years. My understanding is that Rust is going down the same path as C++. So you're going to have 2 kinds of macros AND comptime-like/constexpr-like compile time execution.

steveklabnik 6y ago
Yes, something very similar to constexpr. > Zig simplifies everything by designing in comptime up front, rather than gradually opening it up with ad hoc rules over 10+ years. I am not 100% sure that I agree with these characterizations, personally, but they're both valid strategies for sure.
- girvo 6y ago
  Regardless of the particular trade-offs the various languages under discussion are choosing to make, it’s exciting to me that more and more languages are adapting, exposing and using “compile time” systems