[unscaled]

I'm afraid this article kinda fails at at its job. It starts out with a very bold claim ("Zig is not only a new programming language, but it’s a totally new way to write programs"), but ends up listing a bunch of features that are not unique to Zig or even introduced by Zig: type inference (Invented in the late 60s, first practically implemented in the 80s), anonymous structs (C#, Go, Typescript, many ML-style languages), labeled breaks, functions that are not globally public by default...

It seems like this is written from the perspective of C/C++ and Java and perhaps a couple of traditional (dynamically typed) languages.

On the other hand, the concept that makes Zig really unique (comptime) is not touched upon at all. I would argue compile-time evaluation is not entirely new (you can look at Lisp macros back in the 60s), but the way Zig implements this feature and how it is used instead of generics is interesting enough to make Zig unique. I still feel like the claim is a bit hyperbolic, but there is a story that you can sell about Zig being unique. I wanted to read this story, but I feel like this is not it.

[WalterBright]

D has had compile time function execution since 2007 or so.

https://dlang.org/spec/function.html#interpretation

It doesn't need a keyword to trigger it. Any expression that is a const-expression in the grammar triggers it.

[ScottRedig]

Hello Mr. Bright. I've seen similar comments from you in response to Zig before. Specifically, in the comments on blog post I made about Zig's comptime. I took some time reading D's documentation to try to understand your point (I didn't want to miss some prior art, after all). By the time I felt like I could give a reply, the thread was days old, so I didn't bother.

The parent comment acknowledges that compile time execution is not new. There is little in Zig that is, broad strokes, entirely new. It is in the specifics of the design that I find Zig's ergonomics to be differentiated. It is my understanding that D's compile time function execution is significantly different from Zig's comptime.

Mostly, this is in what Zig doesn't have as a specific feature, but uses comptime for. For generics, D has templates, Zig has functions which take types and return types. D has conditional compilation (version keyword), while Zig just has if statements. D has template mixins, Zig trusts comptime to have 90% of the power for 10% of the headache. The power of comptime is commonly demonstrated, but I find the limitations to be just as important.

A difference I am uncertain about is if there's any D equivalent for Zig having types being expressions. You can, for example, calculate what the return type should be given a type of an argument.

Is this a fair assessment?

[WalterBright]

> A difference I am uncertain about is if there's any D equivalent for Zig having types being expressions. You can, for example, calculate what the return type should be given a type of an argument.

This is done in D using templates. For example, to turn a type T into a type T star:

    template toPtr(T) { alias toPtr = T*; } // define template

    toPtr!int p; // instantiate template

    pragma(msg, "the type of p is: ", typeof(p));

The compiler will deduce the correct return type for a function by specifying auto* as the return type:

    auto toPtr(int i) { return cast(float)i; } // returns float

For conditional compilation at compile time, D has static if:

    enum x = square(3);  // evaluated at compile time
    static if (x == 4)
        int j;
    else
        double j;
    auto k = k;

Note that the static if* does not introduce a new scope, so conditional declarations will work.

The version is similar, but is intended for module-wide versions, such as:

    version (OSX)
    { stuff for OSX }
    else version (Win64)
    { stuff for Windows 64 }
    else
        static assert(0, "unsupported OS");

Compile time execution is triggered wherever a const-expression is required. A keyword would be redundant.

D's mixins are for generating code, which is D's answer to general purpose text macros. Running code at compile time enables those strings to be generated. The mixins and compile time execution are not the same feature. For a trivial example:

    string cat(string x, string y) { return x ~ "," ~ y; }
    string s = mixin(cat("hello", "betty")); // runs cat at compile time
    writeln(s); // prints: hello,betty

I'll be happy to answer any further questions

[baranul]

I appreciate you taking the time to give examples in D. People are often under the mistaken impression that Zig's compile time is revolutionary, from how it is excessively hyped, but are failing to realize that many other languages have similar or users can get similar results by doing things differently, because languages have different philosophies and design strategies.

For example, the creator of Odin, has stated in the past he rather come up with optimal solutions without metaprogramming, despite enthusiasts trying to pressure him to add such features into that language.

[tialaramex]

Maybe I don't understand, in D, how do I write a function which makes a new type?

For example Zig has a function ArrayHashMapWithAllocator which returns well, a hash table type in a fairly modern style, no separate chaining and so on

Not an instance of that type, it returns the type itself, the type didn't exist, we called the function, now it does exist, at compile time (because clearly we can't go around making new types at runtime in this sort of language)

[pjmlp]

You use templates and string mixins alongside each other.

The issue with mixins is that using string concatenation to build types on the fly isn't the greatest debugging experience, as there is only printf debugging available for them.

[WalterBright]

See my other post.

[brabel]

Yes and D's comptime is much more fun, IMHO than Zig's! Yet everyone talks about Zig's comptime as if it were unique or new.

[jhgb]

But Zig doesn't need a keyword to trigger it either? If it's possible at all, it will be done. The keyword should just prevent run-time evaluation. (Unless I grossly misunderstood something.)

[WalterBright]

I'm no expert on Zig, but "comptime" is the keyword to trigger it.

[jhgb]

I'm pretty sure the "comptime" keyword only forces you to provide an argument constant at compile time for that particular parameter. It doesn't trigger the compile time evaluation.

[WalterBright]

That's how the constant is provided - through compile time evaluation.

[jhgb]

Yes, but compile-time evaluation in Zig doesn't require the "comptime" keyword. Only specific cases such as compile-time type computation do (but these specific cases are not provided by compile-time function evaluation in D anyway, so language choice wouldn't make a difference here).

[pron]

Partial evaluation has been quite well known at least since 1943 and Kleene's Smn proof. It has since been put to use, in various forms, by quite a few languages (including C++ in 1990, and even C in the early seventies). But the extent and the way in which Zig specifically puts it to use -- which includes, but is not limited to, how it is used to replace other features that can then be avoided (and all without macros) -- is unprecedented.

Pointing out that other languages have used partial evaluation, sometimes even in ways that somewhat overlap with Zig's use, completely misses the point. It's at least as misplaced as saying that there was nothing new or special about iPhone's no-buttons design because touch screens had existed since the sixties.

If you think Zig's comptime is just about running some computations at compile time, you should take a closer look.

[WalterBright]

I'd like to see an example! as I cannot think of one.

[pron]

An example of what?

[eden-u4]

Not OP, but I guess based on your comment:

> But the extent and the way in which Zig specifically puts it to use -- which includes, but is not limited to, how it is used to replace other features that can then be avoided (and all without macros) -- is unprecedented.

That MrWhite wanted to knkw an example of Zig's comptime that is not merely a "macro", rather the usage as a replacement of other features (I guess more complex..)

PS just interested in zig, I'd like some pointer to these cool feature :)

[WalterBright]

An unprecedented use.

[pron]

Ok, so a primary goal of comptime in Zig is to avoid needing certain specialised features while still enjoying their functionality, in particular, generics, interfaces, and macros. I'm not aware of any language that has been able to eliminate all of these features and replace them with a simple, unified partial evaluation mechanism.

In addition, there's the classic example of implementing a parameterised print (think printf) in Zig. This is a very basic use of comptime, and it isn't used here in lieu of generics or of interfaces, but while there may be some language that can do that without any kind of explicit code generation (e.g. macros), there certainly aren't many such examples: https://ziglang.org/documentation/0.15.2/#Case-Study-print-i...

But the main point is that the unprecedented use of partial evaluation is in having a single unified mechanism that replaces generics, interfaces, and macros. If a language has any one of them as a distinct feature, then it is not using partial evaluation as Zig does. To continue my analogy to the novel use of a touchscreen in the iPhone, the simplest test was: if your phone had a physical keypad or keyboard, then it did not use a touchscreen the way the iPhone did.

[jadbox]

Hi Walter! Big fan. What do you think of Zig? How would you like to see it evolve? Are there any things from Zig that inspire you to work in D?

[WalterBright]

I have never written a Zig program, I've just browsed the specification. I do admire the energy and enthusiasm of its creators. The fast compiles of it are well done.

Mostly what I think is the syntax is more complex with less utility than the equivalent D syntax. For example, the use of the 'comptime' keyword is not necessary. For another, the import declaration is overly complex.

I don't know enough about Zig to make informed suggestions on evolving it. D has borrowed stuff from many languages, but I don't recall suggestions in the D forums of a Zig feature that should be added to D, though I might have missed it.

[rurban]

Perl5 had it before. Either by constant-folding, or by BEGIN blocks.

Constant-folding just got watered down by the many dynamic evangelists in the decades after, that even C or C++ didn't enforce it properly. In perl5 is was watered down on add (+) by some hilariously wrong argumentation then. So you could precompute mult const expressions, but not add.

[zbentley]

How are perl5’s BEGIN blocks equivalent to comptime? It’s been awhile, but I recall BEGIN blocks executing at require time—which, in complicated pre-forking setups that had to be careful about only requiring certain modules later during program execution because they did dumb things like opening connections when loaded, meant that reasoning about BEGIN blocks required a lot more careful thought than reasoning about comptime.

The same is true for templates, or macros—all of which are distinguished by being computed in a single pass (you don’t have to think about them later, or worry about their execution being interleaved with the rest of the program), before runtime start (meaning that certain language capabilities like IO aren’t available, simplifying reasoning). Those two properties are key to comptime’s value and are not provided by perl5’s BEGIN blocks—or probably even possible at all in the language, given that it has eval and runtime require.

[rurban]

BEGIN blocks execute at compile-time. require is just a wrapper to load a module at compile-time.

When you want to use state, like openening a file for run-time, use INIT blocks instead. These are executed first before runtime, after compile-time.

My perl compiler dumps the state of the program after compile-time. So everything executed in BEGIN blocks is already evaluated. Opening a file in BEGIN would not open it later when required at run-time, and compile-time from run-time is seperated. All BGEIN state is constant-folded.

[zbentley]

I think we’re using different definitions of “compile time”.

I know who you are, and am sure everything you say about the mechanisms of BEGIN is correct, but when I refer to “compile time”, I’m referring to something that happens before my program runs. Perl5’s compilation happens the first time a module is required, which may happen at runtime.

Perhaps there’s a different word for what we’re discussing here: one of the primary benefits of comptime and similar tools is that they are completed before the program starts. Scripting languages like perl5 “compile” (really: load code into in-memory intermediate data structures to be interpreted) at arbitrary points during runtime (require/use, eval, do-on-code).

On the other hand, while code in C/Zig/etc. is sometimes loaded at runtime (e.g. via dlopen(3)), it’s compile-time evaluation is always done before program start.

That “it completed before my code runs at all” property is really important for locality of behavior/reasoning. If the comptime/evaluation step is included in the runtime-code-load step, then your comptime code needs to be vastly more concerned with its environment, and code loading your modules has to be vastly more concerned with the side effects of the import system.

(I guess that doesn’t hold if you’re shelling out to compile code generated dynamically from runtime inputs and then dlopen-ing that, but that’s objectively insane and hopefully incredibly rare.)

[pmkary]

When I read "I can easily say that Zig is not only a new programming language, but it’s a totally new way to write programs" I expected to see something as shocking as LISP/Smalltalk/Realtalk/EVE/FORTH/Prolog... A whole new paradigm, a whole new way to program. Or at least a new concept like the pure functionalism of Haskell, or Prototyping like in Lua/JS/Io. And I was so damn shocked how I must have missed something so huge, having read the entirety of Zig's documentation and not have noticed anything? As you mentioned, turned out nothing, and I was shocked then why is it in the top of HN? Also turned out for no reason based on the comments.

[skotobaza]

The idea of modern society is "get hyped for the new thing". Tech crowd did not escape that unfortunately, and keeps rediscovering techniques that were already possible more that 50 years ago. Because they don't want to learn the history of the technology they are using.

[pjmlp]

"Computing is a fashion show"

-- Alan Kay

[wolvesechoes]

Dev celebs makes blogposts and videos on how Zig is awesome and unique, so the herd repeats.

[sparky4pro]

Same can be said about other programming languages. Therefore the comment of yours has zero value…

[wolvesechoes]

Nah, there are many languages ignored or even despised by those dev celebs.

> yours has zero value

Yours didn't bring much as well, so I suppose value isn't strictly required.

[sparky4pro]

Good point.

BTW: Your reply made me laugh so hard… I loved it.

Thanks.

[spacechild1]

> Also turned out for no reason based on the comments.

The reason is the clickbait title.

[phplovesong]

Agreed.

But i would not put comptime as some sort of magical invention. Its still just a newish take on meta programming. We had that since forever. From my minimal time with Zig i kind of think comptime as a better version of c++ templates.

That said Zig is possibly a better alternative to c++, but not that exiting for me. I kind of dont get why so many think its the holy grail, first it was rust, and now zig.

[johnisgood]

As much as I dislike Rust, I gotta give it credit where it's due. It has something unique: a borrow checker. What is so unique in Zig?

[flohofwoe]

> It has something unique: a borrow checker.

Rust's borrow checker isn't unique either but was inspired by Cylone: https://en.wikipedia.org/wiki/Cyclone_(programming_language)

IMHO a programming language doesn't need a single USP, it just needs to include good existing ideas and (more importantly) exclude bad existing ideas (of course what's actually a good and bad idea is highly subjective, that's why we need many programming languages, not few).

[simonask]

Rust's borrow checker is unique in the sense that it is production-ready. Cyclone is indeed prior art, but it's not as if it ever got beyond the research project stage.

[johnisgood]

I don't necessarily disagree, of course. That is why I like Odin the most so far, and perhaps C3.

[HarHarVeryFunny]

> I'm afraid this article kinda fails at at its job

Yeah, I know nothing about Zig, and was excited by the author's opening statement that Zig is the most surprising language he has encountered in a 45 yr software career...

But this is then immediately followed by saying that ability to compile C code, and to cross-compile, are the most incredible parts of it, which is when I immediately lost interest. Having a built-in C compiler is certainly novel, and perhaps convenient for inter-op, but if the value goes significantly beyond that then the author is failing to communicate that.

[brabel]

The code samples are so weird... Some are images, others are not, and there's like 10 different color schemes (even among the textual ones, it's not consistent). That actually takes some kind of effort to achieve :D.

[bdangubic]

gives you a preview of the experience of using it :)

[wseqyrku]

> Zig is not only a new programming language, but it’s a totally new way to write programs

I'd say the same thing about Rust. I find it the best way to express when what code should run at any given point in the program and the design is freakin interstellar: It is basically a "query engine" where you write a query of some code against the entire available "code space" including root crate and its dependencies. Once you understand that programming becomes naming bits and then queries for the ones you wish to execute.

[JoeyJoJoJr]

As someone not really familiar with Rust, this sounds intriguing, but I don’t full understand. Do you have any links that can or examples that could clarify this for someone who is just starting out with Rust?

[vacuity]

Not GP, but I genuinely don't understand what GP is talking about.

[Shorel]

Compile time seems to be a standard feature in D-lang as well.

Powerful macros that generate code that then gets compiled =)

[nwhnwh]

"this article kinda fails at at its job"

Definitely.

[jb1991]

> C/C++

It has been several decades since putting a slash between these two made sense, lumping them together like this. It would be similar to saying something like Java/Scala or ObjectiveC/Swift. These are completely different languages.

[pjmlp]

Nope, that is a English grammar construct that is a shortcut for "and" and "or", as any good English grammar book will explain.

Indeed you see those for Java/Scala and Objective-C/Swift in technical books and job adverts.

Any search on the careers sites, or documentation, on companies that have seats at ISO, sell/develop C and C++ compilers, have such C/C++ references in a couple of places.

Do you need any example?

[1718627440]

In the general case yes, but "C/C++" became an idiom for the stance, that C and C++ are essentially the same, that C++ is a superset of C or that C++ is just the replacing successor of C and it should be treated as superseded. This is quite wrong and thus there is a lot of rightful intervention to that term. Personally I use "C, C++" when I want to talk about both without claiming, that they are the same language.

[pjmlp]

Nah, that is what pedantic folks without English grammar knowledge keep complaining about, instead of actually discussing better security practices in both languages.

It is a bikeshedding discussion that doesn't help in anything, regarding lack of security in C, or the legions of folks that keep using C data types in C++, including bare bones null terminated strings and plain arrays instead of collection types with bounds checking enabled.

[jb1991]

This has nothing to do with bikeshedding, it is a genuine misunderstanding of these two languages that is propagated in this way. This is not about grammar.

[pjmlp]

Yet those complaining usually make use of plenty C constructs, data types and standard library on their C++ projects, instead of modern C++ practices.

[1718627440]

In my opinion, this is an important issue and not "bikeshedding", but it can be discussed whether the term "C/C++" is always an example of that idea or not. I think it is not, but it is connected enough, that I won't use it to side step the issues.

[pjmlp]

So there will be zero C language constructs, and C standard library functions being called, on your C++ source code?

[jb1991]

Not in this context, that’s incorrect.

[pjmlp]

What context?

The pedantic folks that jump of their chair when seeing something all companies that pay WG21 salaries use on their docs?

If only they would advocate for writing safer code with the same energy, instead of discussing nonsense.

That is why C and C++ communities are looked down by security folks, and governments.

[tmtvl]

The problem is that it's a bit tricky to type the intersection symbol (∩), because C ∩ C++ makes more sense.

[1718627440]

Anonymous structs and type interference are things even C has, although support for the later one is quite recent and limited.

[pjmlp]

Yeah, as I keep repeating, it is a Modula-2 in C clothes, minus comptime, which as others have mentioned D has had for quite some time.

[tourist2d]

As a c++ developer who's heard of Zig but never dived into it, I was reading this article scratching my head wondering what is it actually so unique about it.

Why the blog has a section on how it install it on the path is also very puzzling.

[bnolsen]

Zig is simple, clever and clean. certainly not perfect but it addresses much of what I disliked about c++. I wanted to like D and rust but they seem just as complex as c++. Yes, better in some ways but still full of complexity.

[otabdeveloper4]

> C/C++

No such thing. Also C++ has most of those features too.