Instinctually I’m bothered by passing an allocator to everything. LISP’s dynamic variables spring to mind. One could set an arena allocator at the top of a loop in a dynamic variable and then everything inside the loop would use that allocator. The bottom of the loop could free everything. Although I do really like knowing if something might call an allocator, perhaps a function specifier to indicate it allocates.

Although I’m intrigued by another idea I haven’t thought through. Haskell requires all function side effects to essentially propagate a description of the side effect up to main() where Haskell executes the side effect. There is also the idea of imperative shell, functional core that I don’t fully grasp. In any case perhaps all side effects should execute at the top level or maybe in a parallel environment and here passing an allocator would not be so onerous.

That might violate the no implied behavior rule that zig has.

I disagree on many points the article makes, but it is well written and lays out its arguments well.

One example - I prefer the named fields of Zig over Odin's use of positional fields. Zig's syntax is the more popular one as of late, heck even C has named struct member initialization.

IMHO Positional is just asking for trouble. Yes it works fine for game programming, and not having to specify x and y thousands of times in a code base is nice, but for general purpose languages where a struct can have a dozen+ fields to init, positional assignment is how bugs are made.

C gives either, I think that is the true with Odin as well, it certainly is for C3. I was assuming Zig allowed both. Is this another one of Zig being strict with ”only one way”?

You can simply offer a function to create an object using positional arguments if you want that

You can also create a function capable of doing that for any object, or one which curries the type parameter, if you'd like to reduce the boilerplate if you have many types of objects you'd like to instantiate positionally.

I am only giving my impressions. Coming from other languages, this was very confusing, and the error messages were not helpful.

I stumbled across Zig by a reference to it as part of the Bun (JS engine) documentation.

I didn't find the Zig language benefits sufficiently compelling to learn yet another opinionated language.

Since much of my work is with embedded and bespoke systems, I did find the Zig cc front-end to LLVM convenient. Maybe it's because I haven't sufficiently mastered Clang for cross-compilation.

I’m using zig for embedded builds currently. All of the mcu files are still in C (arm thumb isn’t first class supported in zig) but the host software is sometimes zig. Being and to easily develop on and for any host platform is such a pleasure. I can just tell junior devs to download zig and a vscode extension and they’re off to the races.

I like the try/catch of Zig. It is innovative.

Moreover Zig is a research playground. Ideas will find their way to D/Nim.

Zig CC is another innovation.

The compile time is also a great experiment.

It brings a lot to the table.

May not be a total C replacement, but it is an improvement and lots of C code, can be written in Zig. Lots of people can be introduced to Systems Programming with Zig. For Low Level coding, have you heard of FASM? Better than C in my opinion.

What people want today is easy cross platform coding, something poorly served by C, but served much better by both Zig and Odin.

The ease of using Odin over Zig for Raylib was an interesting contrast that I hadn’t reflected on myself. I tried to do things well with C3, but it might be hard to beat Odin on that particular point.

I just wonder how well it will work long term with update cycles and such. Zig and C3’s decentralized model seems easier for handling frequently updating libraries.

It's cool that it's so easy with Odin, but I think whether it takes one minute to set up Raylib with Odin or three minutes with Zig or C3 is pretty insignificant for any real project.

I think the author's criticism of the named initializer requirement is emblematic of a big problem I have with most new languages. The author says that it makes things like vectors more verbose and awkward, which is true.

My counter to this is: who gives a shit? I'm not writing a vector library or a game engine; I'm writing systems code, and unnamed initializers are harder to read and expose code to subtle bugs. And for what? So that vectors look prettier?

A lot of programming language design seems to prioritize making its own standard library math functions more elegant to implement, which I find to be very irritating, and Zig is a breath of fresh air in this regard.

> the language motto is “No hidden control flow”.

Oh man, I wish the Haskell crowd gave at the very least lip service to that type of idea.

If you like that idea you might like my library Bluefin, where even throwing exceptions requires an explicit value telling you where control will return to.

https://hackage.haskell.org/package/bluefin

For the Bitshifters author: could you do a review of the V language as well?

Yes.

It is here: https://bitshifters.cc/2025/05/17/vlang.html

The full list of articles:

Jai: https://bitshifters.cc/2025/04/28/jai.html

Odin: https://bitshifters.cc/2025/05/04/odin.html

Zig: https://bitshifters.cc/2025/05/04/zig.html

V: https://bitshifters.cc/2025/05/17/vlang.html

C3: https://bitshifters.cc/2025/05/22/c3-c-tradition.html