Zig has completely changed the way I program (even outside of it). A lot of the goals and heuristics I used to have while writing code have completely changed. It's like seeing programming itself in a new way.

Perhaps I'm missing something but this is utterly routine. It even has the name used here: Cross-compiling.

It basically looks like C with different syntax, im also not convinced the 0…9 implicit range is better for iteration - i prefer it explicitly for lower level languages.

I don't find Zig nearly as readable as my D code, but alas, I don't do systems programming.

its a hipster language, absolute insanity to use it when rust exists unless you have that very specific c related slave work to do

"When a Go project utilizes CGo to interact with C code, standard Go cross-compilation might require additional steps. This is because Go can cross-compile Go code but not C code directly, necessitating the availability of target system libraries on the development machine. Tools like Zig can be used as a C compiler (zcc) to facilitate cross-compilation for CGo-dependent projects by providing the necessary cross-compilation capabilities for the C code."

They allow for super ergonomical coding of state machines, which is a lot of fun.

It seems that (debug) allocators are a nice idea, however, it seems that they exist "somehow" already for C, so I wonder: why would you pick this language for your next low level program? They provide runtime checks, so you need thorough testing before you can spot use-after-free or so. It's very similar to the existing situation with c/c++ and the sanitizers, although they work a bit differently.

So the question I have for hardcore low level programmers: why don't they invest more on the memory allocators like hardened_malloc[0] instead of starting a new programming language? It would probably be less expensive in terms of time and would help fix existing software.

[0]: https://github.com/GrapheneOS/hardened_malloc

To me it seems like a better C but not at all unique since most concepts in Zig are already present in other languages.

Zig is cool but not unique. And that is cool, too. Originality for the sake of originality doesn't add value in programming.

(also expected tesseract to do a bit better than this:

  $ wl-paste -t image/png | tesseract -l eng - -
  Estimating resolution as 199
  const std = @import("std");
  const expect = std.testing.expect;
  
  const Point = struct {x: i32, y: i32};
  
  test "anonymous struct literal" {
  const pt: Point = .{
  x = 13,
  -y = 67,
  33
  try expect (pt.x
  try expect(pt.y
  
  13);
  67);

)

in fact files in zig are just structs !

    ldd your-zig-executable :)

>>>

Labeled breaks

Zig can do many things in compilation time. Let’s initialize an array, for example. Here, a labelled break is used. The block is labelled with an : after its name init and then a value is returned from the block with break.

>>>

The article hasn't even talked about how the language decides what an open curly brace is causing.

I like the simplicity and speed of Rust's eGUI. Something similar for Zig would be amazing.

https://survey.stackoverflow.co/2025/technology

Inserting the literal one byte instruction (on x86) - INT 3 - is the least a compiler should be able to do.

Does the feature end up feeling unused, dominating app code with test code, or do people end up finding a happy medium?

Then HN proceed to keep the article at the head of the front page for the day.

Btw it's so much easier to add an environment variable in linux, I haven't used windows since 2007 so it was interesting for me to see how you do it there. Clicking on edit buttons to find that menu ? Nah, I don't do that here :)

In Zig and C, it's always expected that you will explicitly manage your lifetimes. Zig uses the allocator interface to explicitly allocate new buffer or heap values and its keyword 'defer' to clean up allocated variables after the scope exits so that allocations and frees generally live next to each other.

C on the other hand, is relatively unopinionated about how lifetimes are managed. The defer keyword honestly takes most of the pain of managing lifetimes away.

Zig is actually perfect for production network services (that’s all TB is essentially, or how I see it, and what I was looking for in Zig—how to create something with explicit limits that can handle overload—it’s hard to build anything production-grade if it’s not doing NASA’s Power of Ten and getting allocation right—GC is not a good idea for a network service).

I wouldn’t say Zig’s std lib is immature. Or if anything, it has higher quality than most std libs. For example, the unmanaged hashmap interface is :chefskiss. In comparison, many std libs are yet to get non-global allocators or static allocation or I/O right.

See Dijkstra for why this is the right way to represent ranges: https://www.cs.utexas.edu/~EWD/transcriptions/EWD08xx/EWD831...

You could go further like in this case, and use wheels + PyPi for something unrelated to Python.

Or I should say it was useful as a distribution method, because most people had Python already available. Since most distros now don't allow you to install stuff outside a venv you need uv to install things (via `uv tool install`) and we're not yet at the point where most people already have uv installed.

In a language where half-open intervals are supported consistently in all the places, this would be solved trivially, e.g. for a signed byte the _MIN and the _MAX values would be defined as -128 and +128, more intuitively than when using closed intervals, where you must remember to subtract 1 from the negated minimum value.

Even the C language has some support for half-open intervals, because the index pointing after the last element of an array is a valid index value, not an out-of-range value (though obviously, attempting to access the array through that index value would be trapped as an out-of-range access, if that is enabled).

Applied consistently, the same method would ensure that the value immediately above the last representable value of an integer type is valid in ranges of that type, even if it would be invalid in an expression as an operand of that type.

There might be a few pathological code paths in the core libraries or whatever for certain things that aren't what they should be, but in terms of the raw language you're in the land of C as much as with any of these languages; Odin really doesn't do much on top of C, and what it's doing is identifiable and can be opted out of; if you find that a function in a hot loop is marginally slower than it ought to be, you can make it contextless, for example, and see whether that makes a difference.

We haven't found (in a product where performance is explicitly a feature, also containing a custom 3D engine on top of that) that the context being passed automatically in Odin is of much concern performance-wise.

Out of the languages mentioned Rust is the one I've seen in benchmarks be routinely marginally slower, but it's not by a meaningful amount.

#!/usr/bin/env rdmd

[D code]

and run it as if it were an executable. (The compilation is cached so it runs just as fast on subsequent runs.)

  #!/usr/bin/env rdmd
  D code...

I would love to see Rust get compile-time execution that is as capable as Zig or C++20.

Or to phrase that more directly at the point: for monolithic kernels to be obsolete you have to break up the monolithic part, not just shim a microkernel hypervisor on top of it.

  for i in 0..length {
    …
  }

  for i in 0..=maxindex {
    …
  }

2 years later, already enjoying it in Zig `defer` is a lot less important to me now. But I still view it as a symptom of the death of the language. C isn't dead, by any stretch of the imagination, but it's no longer learning from it's mistakes, where as I still am.

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.

-- Alan Kay

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.

Check back in on Zig after another decade.

For example, in this test case:

https://gcc.godbolt.org/z/j3Ko7rf7z

GCC generates a store followed by a load from the same location, because of the asm block (compiler barrier) in between. But if you change `if (1)` to `if (0)`, making it use `std::launder` instead of an asm block, GCC doesn't generate a load. GCC still assumes that the value read back from the pointer must be 42, despite the use of `std::launder`.

But what's the Zig equivalent?

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));

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

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

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");

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

This is what I've started doing for every library I use. I go to their Github, download their docs, and drop the whole thing into my project. Then whenever the AI gets confused, I say "consult docs/somelib/"

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

Skipping other minor changes.

However I do agree C# is adding too much stuff, the team seems trying to justify their existence.

I’d like my parser library to be able to give me the exact file, line and column number an error occurred. But I’d also like to use the library in a “just give me an error if something failed, I don’t really care why” mode.

With that said, I'll try it out. I'm not really impressed by what I've seen so far, though, it's very middle-of-the-pack with some really nonsense ideas. The possibility of easily creating your own checks with the compile-time machinery is potentially interesting but would probably turn into a nothingburger for us.

I think that's where most of this is at: After so many years of "waiting" (I think most people stopped actually waiting after a few years of mostly talking and very little actual productive doing) we'll end up with a very meh language that was touted as super special... And a painfully simple sokoban game that people are going to pretend is somehow super complex and hard to make.

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.

If i found no consistency id be making a post like OP but from a different perspective.

This just shows that you weren't around for pre-1.0 Rust. Back then Rust was infamous for the language making breaking changes every week. Check out this issue from 2013 tracking support for features which were deprecated but had yet to be removed from the compiler: https://github.com/rust-lang/rust/issues/4707 , and that's just a single snapshot from one moment in Rust's prehistory.

Try making a similar change between version 5.0 and 6.0, with hundreds of thousands of existing users, programs, packages and frameworks that all have to be updated. (Yes, also the users who have to learn the new thing.)

Let me guess: they didn't, and now there is a third-party "right" way to do it.

(We've been here before, many times.)

I still write about C anyway. It may not trend, but it lasts.

Funny they mention Java that has got type inference few years now. Even C got a weaker version of C++'s auto in C23.

If you look at the current Zig website the hello world example doesn’t compile because they changed the IO interface. Something as simple as writing to the console.

It’s easier to get things right if you have no issues breaking backward compatibility for a decade. It feels it’ll be well over 10 years before Zig is “1.0”.

Articles about C never get much traffic, but that is fine. I wrote it because I care about how things really work, not because I expect it to trend. If even a few people read it and see the beauty in the old language that still runs the world, that is enough.

Of course both Zig and Rust are good languages. But my experience, and I believe your experience will be too if you try to compile programs of similar complexity using standard practices of each language, is that Zig compiles much more compactly in .ReleaseSmall mode than Rust does even with optimization flags, which makes it more ideal for embedded systems, in my opinion. I learned this on my own by implementing the same library in both languages using standard default practices of each.

Of course, at the desktop runtime level, binary size is frequently irrelevant as a concern. I just feel that since Zig makes writing "magic" code more difficult while Rust encourages things like macros, it is much easier to be mindful of things that do impact binary size (and perhaps performance).

> I have never deployed any production C code and I would not choose C for professional work either

What do you write about C, if not for practical usage in the industry? Can you post some links?

FWIW, since you seem interested, here are some blog posts of mine specifically about practical usage of C, some of which got a little discussion here on HN in the past:

https://www.lelanthran.com/chap13/content.html

https://www.lelanthran.com/chap9/content.html

https://www.lelanthran.com/chap5/content.html

I've already replied to you in a sibling post, but I have been writing in C since the mid-90s; there's really not that much insight you get specifically to C.

Am I old? I am 31, and I started with C around age 14 (writing mods for ioquake3 forks), been my most used programming language ever since.

Programming with it is magical, and its a huge drag to go back to languages without it. Just so much better than common OOP that depends only on the type of one special argument (self, this etc).

Common Lisp has had it forever, and Dylan transferred that to a language with more conventional syntax -- but is very near to dead now, certainly hasn't snowballed.

On the other hand Julia does it very well and seems to be gaining a lot of traction as a very high performance but very expressive and safe language.

The need for this jumped out at me during Writergate. People had alot of trouble understanding exactly how all the pieces fit together, and there was no good place to document that. The documentation (or the code people went to to understand it) was always on an implementation. Having an interface would have given Zig a place to hang the Reader/Writer documentation and allowed a quick way for people to understand the expectations it places on implementations without further complications.

For Zig, I don't even want it to automatically handle the vtable like other languages...I'm comfortable with the way people implement different kinds of dynamic dispatch now. All I want is a type-level construct that describes what fields/functions a struct has and nothing else. No effect on runtime data or automatic upcasting or anything. Just a way to say "if this looks like this, it can be considered this type."

I expect the argument is that it's unnecessary. Technically, it is. But Zig's biggest weakness compared to other languages is that all the abstractions have to be in the programmer's head rather than encoded in the program. This greatly hampers people's ability to jump into a new codebase and help themselves. IMO this is all that's needed to remedy that without complicating everything.

You can see how much organizational power this has by looking at the docs for Go's standard library. Ignore how Go's runtime does all the work for you...think more about how it helps make the _intent_ behind the code clear.

That's not error data, that's (one level of) a stack trace. And you can do that in zig, but not by putting call stack data into error return codes.

The conflation between exception handling and error flagging (something that C++ did largely as a mistake, and that has been embraced by managed runtimes like Python or Java) is actually precisely what this feature is designed to untangle. Exception support actually turns out to have very non-trivial impact on the generated code, and there's a reason why languages like Rust and Zig don't include them.

C, yes, you can compile C quite small very easily. Zig is like a simpler C, in my mind.

So no, it's not as safe as rust in terms of memory, but it's quite close, and in the process lets you do some really cool stuff.

But destructors also don't conditionally interrupt the flow of execution, and always run at the end of a block.

> If I see a defer

The point is that you're not seeing it. In order to know if there's a defer happening at the end of a function you can't just read the end of the function, you need to read the entire function. That's non-local reasoning, which is what Zig professes to abhor.

And in fact defer is worse than destructors here, because a destructor runs the exact same code every time, whereas defer allows arbitrary code, so you need to review every single usage. And you also need to remember not to forget to use it in the first place (which is the classic footgun with defer), so in addition to vetting everywhere you use it, you also need to vet everywhere you might have forgotten to use it.

“Low-level” languages — Rust, C++, D

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.

what gets me personally is what you describe at https://github.com/little-book-of/c/blob/main/articles/zig-i... - zig is made to feel easy and modern for people who don't know any better, and it does this well. But as soon as you actually need to do complex stuff, it gets in the way moreso than C and it's current environment/ecosystem will.

And to be fair, as much as I enjoyed writing in C in my younger years - I only use C when I actually need C. And asm when I actually need asm. Most of my code now uses higher level languages - this puts zig into such a niche.. it feels like golang to me: the cool language that isn't really solving as much of a need as you'd think.

Have you used it in any large projects?

IIRC there's also a mutex somewhere in there used to workaround some threading issues in libc, which brings in a bespoke mutex implementation; I can't remember whether that mutex can be easily disabled, but I think there's a way to use the slower libc mutex implementation instead.

Also, std::fmt is notoriously bad for code size, due to all the dyn vtable shenanigans it does. Avoid using it if you can.

Regardless, the only way to fix many of the problems with std is rebuilding it with the annoying features compiled out. Cargo's build-std feature should make this easy to do in stable Rust soon (and it's available in nightly today).

> what the heck does it matter what "much of the standard library uses" to this issue?

It matters in that most people looking for a low level manually memory managed language won’t likely choose D, so for the purposes of “is this relatively novel among lower level, memory managed languages” D doesn’t fit my criteria.

> Even C now has type inference. The plain fact is that the claim is wrong.

Almost no one is using C23 yet.

As for the other ones I listed,

https://en.wikipedia.org/wiki/Mesa_(programming_language) (some PDFs linked from there)

https://bitsavers.org/pdf/borland/turbo_pascal

https://www.freepascal.org

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi_D...

and

https://learn.adacore.com/index.html

http://www.ada-auth.org/arm.html

What do you mean? All the keywords in the standard language are ASCII. And even if you meant some other part of the standard language, they're (almost) all ASCII too.

(The most notable exceptions are use of superscript 0 thru 9 for powers -- eg `2¹⁶-1 == 65535` -- and the `«` and `»` characters, which are part of the Latin-1 aka "8 bit ASCII" character set, are aliases for the (7 bit) ASCII `<<` and `>>` tokens. I understand these exceptions may concern you, but can assure you they're not really a problem in practice.)

> The problem with sigils is that they compose poorly when casting

Are you thinking Raku sigils are like sigils in other languages, eg Perl or Javascript or PHP?

From my perspective one of the several _strengths_ of Raku's sigils is that they combine succinct compile time type constraints and composition.

Just type `@` (reads as "at") to denote a compile time enforced type constraint for the `Positional` interface, an abstract/generic datatype for any iterable integer indexed collection.

So, if you have an array of points, Raku will happily let you store it in a variable named, say, `points-array`, but naming it `@points` means Raku will compile time enforce binding of that name to an integer indexed collection and visually reflect that that is so for any human glancing at the code.

As for "casting", if you want to treat `@points` as a Single Item ("a single array of points") then just write `$@points` -- the `$` reads as Single Item -- `S` over `I`.

(Technically speaking that's not time consuming casting, but just stripping off an indirection, the optimal optimization of that scenario, but I am guessing this is semantically the kind of thing you meant.)

> (refs, counts)

Again, are you thinking that Raku's sigils are like other languages'? (They're not.)

> and do not generalize to other types.

Again, are you thinking that Raku's sigils are like other language's sigils? They are not.

Raku's `$` sigil is the generic Single Item interface for any datatype. (It can be parameterized with a data structure's typed structure.)

The `&` sigil is the generic Single Item interface for any function type. (It can be parameterized with a function's type signature.)

The `@` sigil covers any integer indexed collection. (It can be parameterized with the collection's fixed length for a fixed size array, or shape for a multidimensional structure. To parameterize a nested heterogeneous data structure's type signature, use `$` instead.)

The `%` sigil covers any name indexed collection. (It can be parameterized with the collection's key/value types. To parameterize a nested heterogeneous data structure's type signature, use `$` instead.)

> Plus, they seem to encourage the language designers to implement semantic that is "context aware" which would have been another billion dollars mistake if perl had become more popular.

Why are you mentioning Perl in a subthread about Raku? Are you aware the language was renamed precisely because so many people were completely misunderstanding the nature of Raku?

> In other words, that's unnecessary complexity bringing the attention to a poor type system. A bad idea that deserves to die, in my opinion.

If you're thinking of Perl's type system and applying what you know of that to Raku's, that's like thinking Python's type system is like Haskell's. They are very different.

What Ada (and Rust) calls generics is very different -- it is like template functions in C++.

In those languages the version of the function that is selected is based on the declared type of the arguments.

In CLOS, Dylan, Julia the version of the function that is selected is based on the runtime type of the actual arguments.

Here's an example in Dylan that you can't do in Ada / Rust / C++ / Java.

    define method fib(n) fib(n-1) + fib(n-2) end;
    define method fib(n == 0) 0 end;
    define method fib(n == 1) 1 end;

The Julia version is slightly more complex.

    fib(n) = fib(Val(n))
    fib(::Val{n}) where {n} = fib(n-1) + fib(n-2)
    fib(::Val{0}) = 0
    fib(::Val{1}) = 1
    
    println(fib(30))

This of course is just a function with a single argument, but you can do the same thing across multiple arguments.

    define method ack(m, n) ack(m-1, ack(m, n-1)) end;
    define method ack(m == 0, n) n+1 end;
    define method ack(m, n == 0) ack(m-1, 1) end;

If Wikipedia has deadnamed Raku with grace then that might be a model to follow, but in general it's far from helpful unless it's done carefully. There's a reason why the community embarked on the somewhat painful multi decade process of renaming it. To try clarify my understanding I'll summarize it here.

Because of the original name for Raku, people assumed for a long time (long after it became problematically misleading) that it shared semantics, or syntax, or compiler tech, or libraries, or something technical like that, with some other programming language(s).

This was partly because Raku did indeed take some inspiration philosophically and/or technically from some existing languages (traces of a half dozen or so are evident), and partly because Raku and its compiler tech features the ability to use Python code and compilers, and C code and compilers, and Perl code and compilers, and so on, as if they were native Raku code/compilers.

But Raku was never C, or Python, or Perl, and the old name is unfortunately a form of deadnaming -- which is to say, something that is seldom helpful, especially if some commentary like this comment is not included.

At least, that's how I experience it.

That said, regardless of my view, I love your impulse of being helpful, which is why I've written this -- and I hope it does help any readers.

And this is exactly the stance I am arguing against. C++ is not the newer version of C. It forked of at some point and is a quite different language now.

One of the reasons I do use malloc for, is for compatibility with C. It is not for backward compatibility, because the C code is newer. In fact I actively change the code, when it needs a rewrite anyway, from C++ to C.

The other reason for using it even when writing C++ is, that new alone doesn't allow to allocate without also calling the constructor. For that I call malloc first and then invoke the constructor with placement new. For deallocating I call the destructor and then free. This also has the additional benefit, that your constructor and deconstructor implementation can fail and you can roll it back.

Again, the novel use of partial evaluation in Zig is that it eliminates generics, interfaces, and macros. Any language that has one or more of these features does not have this novel design.

It's like how the novelty of the iPhone's touchscreen design was in not having a keypad, or that the novelty of the spork wasn't in inventing the functionality of either the spoon or the fork, but in having a single utensil that performs both. The more important aspect isn't the functionality but the design. I'm not saying you need to like any of these designs, but they are novel.

Saying that you could have a similar functionality by other means misses the point as much as saying that there's nothing special about a spork because if you have a spoon and a fork, then you have the same functionality. But you still don't have a spork.

You could, then, ask what the point of the novel design is. Well, in some languages you have generics and interfaces and compile-time expressions, but because none of these is general and powerful enough, so you also have macros. Macros are very powerful - perhaps too powerful - but they are difficult to understand, so they're used sparingly even if they can subsume other functionality.

Zig has shown that you can do almost anything you would reasonably want to do with macros with partial evaluation that has access to reflection. That wasn't obvious at all. And because that feature was not only powerful enough to subsume other features and make them redundant, but also very simple and easy to understand, it ended up with a design that is both minimal and easy to read (which is important for code reviews) but also highly expressive. Again, you don't have to like this rather minimalistic design, but it is novel.

That is what writing proper modern C++ is all about, anything else is writing C in C++.

Null terminated strings with pointer arithmetic instead of std::string and string_view, pointer arithmetic instead of std::span, bare pointer arrays instead of std::array and std::vector, C style casts,....