Hacker News Reader

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.

(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.

Oops, sorry. I meant that macros are referentially opaque, and therefore strictly more expressive than comptime: 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.

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 (though it's very immature)

Let's say it's a love-child of ML and C++.

C++ is closer to ML than to C.

Definitely not; what do they have in common beyond being statically typed and compiled?

Where they differ: memory safety, sum types (don't tell me std::variant is a valid replacement), move semantics, having pointers, classes, GC vs RAII, statement vs expressions... That's a lot of differences.

> ...beyond being statically typed and compiled?

What do you mean 'beyond'? It's not like there are many other languages that have compile-time polymorphism. (Java, Go, C, etc., don't.)

> memory safety, sum types (don't tell me std::variant is a valid replacement), move semantics, having pointers, classes, GC vs RAII, statement vs expressions... That's a lot of differences.

ML ignores the real performance and architecture considerations, so yeah, of course it is a simpler and more 'elegant' language. As a teaching aid, yeah, I think all C++ programmers should be forced to program something in an ML-derived language.

But once you start handling the real-world edge cases and requirements you'd end up in a place very similar to C++.

> What do you mean 'beyond'? It's not like there are many other languages that have compile-time polymorphism. (Java, Go, C, etc., don't.)

Java does, it's called generics. Also D, rust, Ada, free pascal, nim, and most statically typed languages from the last 3 decades (even Go is finally getting them ). Still can't see why C++ is closer to ML than C, since it's literally an almost compatible superset of C.

> Java does, it's called generics.

No, Java is still pointers to Object and dynamic dispatch under the hood. Generics didn't change this at all.

> Still can't see why C++ is closer to ML than C, since it's literally an almost compatible superset of C.

ATS is also 'literally an almost compatible superset of C'.

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.

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

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)

The implementation of the pinned keyword proposed here should fix most if not all @fieldParentPtr() footguns https://github.com/ziglang/zig/issues/7769

> 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.

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

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.

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.

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

> 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?

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