I'm not rooting for Zig [1] but I think there are some misses here, e.g.:
> Cross-compilation looks like a standout feature in Zig, although C developers have been doing the same thing for decades. ... You can target an embedded ARM board or a RISC-V chip with one flag:
Disagree: Zig's cross-compilation support is better than anything else. For one, installing a toolchain for a different OS/arch combo is not necessarily so easy with C. For another, with Zig you can target an arbitrary Linux glibc version with a commandline argument. Without Zig's toolchain, [2] the best I've seen is to run within a Docker container with that glibc version installed.
[1] almost entirely because I think all new languages should have memory safety (via GC or borrow checking).
> [2] the best I've seen is to run within a Docker container with that glibc version installed.
Agreed. I will revise that section tomorrow. Also, for compiling Go with CGO enabled, using Docker is the only reliable way to produce a binary correctly linked against glibc, especially when working with RHEL.
generally speaking, cross compilation is a solved problem for common cpus on the market. on linux it's an installation step away, prepackaged and ready to use.
for newer chips or some vendor-optimized-purpose etc, you have to rely on vendor's SDKs, zig can not help there either.
The selling point is not merely cross-compilation; as pointed out in the other thread, it's the any-to-any cross-compilation for any supported target. With Zig, you get to download the compiler for any supported host target and then build binaries for Linux, macOS, Windows, FreeBSD, and NetBSD. In the near future, I intend to expand that list to include OpenBSD, illumos, and SerenityOS too.
I really appreciate the enormous amount of work that has gone into Zig.
Let me clarify my goal here: by writing this article I hope to hear solid counterpoints to the first one, which I didn't find very convincing, and to start a more constructive discussion.
I'm also curious, how hard is it to a new target in Zig? For example, FreeBSD and NetBSD are already supported, but OpenBSD isn't yet. What are the main challenges blocking that?
It's not just a matter of who is a moderator. It can be about the topic, what you are saying, or guideline issue. For clarification, you have to email HN.
none of this needs to be batteries-included, and there is no reason it cannot be done just as straightforwardly for C-family languages as it has been for Zig and Rust.
This is true of almost everything: it's not that Zig or Rust are unique on most features. Most of them have existed in one shape or another before. The praise they receive is because of the level of polish their design and implementation have and how they interact with their other features. There's no one stopping other projects from doing the same thing (modulo technical and organisational considerations), but they haven't yet, so it is reasonable to highlight them. If people talk about how good X is in language Y enough, people from language Z might notice and "steal" it. That's a good thing!
I’m saying these things aren’t “language features” at all. I applaud their creation, but “batteries built in” has always seemed to me like a terrible design decision compared to “batteries provided” especially considering that many of these things would have been perfectly satisfactory generic tooling. Now we have people yapping about C++ not having a build system because they’re all habituated to a world where every language has its own, different build system built in.
> *Some parts of this article were refined with help from LLMs to improve clarity and technical accuracy. These are just personal notes, but I would really appreciate feedback: feel free to share your thoughts, open an issue, or send a pull request!*
Lmao, probably. I'm not going to trust anything else this person has written, since this has proven to me he's writing about things he has little experience with.
I really wish I could like zig more, I started using it heavily around 0.11, but I feel like as more features get implemented there is more that I like and more that I hate.
They've recently fallen into the trap of the wrong whitespace will now error compilation, which has effected me directly.
All the none blocking IO was stuck behind async, which when I was trying to use it it literally didn't exist (this might have changed in 0.15 from the videos I've seen, but all my code fails to compile now do to the former issue with whitespace).
I might come back at Zig 1.0 as long as some of the stupid decisions can be reverted or worked around in some way I find acceptable, otherwise I might just fork it myself to fix it so I can still have some fun with the language.
The Zig self-contained toolchain is one of the most appealing feature IMO, and it can also be used to compile C.
That said, I was very interested in Zig 2-3 years ago but that has mostly cooled off, C is not perfect but good/flexible enough for what I am building.
Zig has some opinionated language features/idiosyncrasies that I don't like and the syntax feels somewhat less clean.
Also, while I really like the memory management approach (passing allocators as parameters) the way it is implemented is conflicting some of my needs. There are probably some workarounds but I don't feel the need to invest much time in this language as the added QoL benefits are not simply not outweighing the cost for me.
C is too verbose, Zig has too many features and things.
I would rather have some sort of "improved C", without the complexity of C++, but with things map, string, vector math, etc, just standard quality-of-life stuff.
Zig has the same problems rust has: its syntax is too complicated, too modern and sophisticated.
Language designers need to understand that programmers are not always patient, smart or motivated to learn all those things. It's the 101 of user experience: make it easy and intuitive.
The programming language who dominate, dominate because they are accessible to lesser skilled people.
The more complex it is, the fewer chance it will reach adoption.
> Zig's compiler is self-contained. It includes a build system, cross-compilers, and package management features. This makes it simple for small projects or single-language codebases.
> C follows a different philosophy. Its toolchain is composable. The compiler, linker, build system, and package manager are independent pieces. You can use GCC or Clang, build with Make or Ninja, manage dependencies with apt or brew, and link with ld, lld, or mold.
Zig would be more composable, as rather than being separate programs, you can write code to compose them in different ways. You are composing in zig rather than bash.
I see it a bit differently. Zig's toolchain is self-contained: one binary gives you the compiler, build system, cross-compilers, and a package manager. It doesnt depend on the system toolchain, which makes builds reproducible and easy to move between machines.
C's ecosystem is the opposite. It is modular, built from separate tools like GCC, ld, Make, and apt. You compose them externally.
> But before Zig, there was C. For fifty years, C has been the foundation of modern computing.
And for fifty years, language theory has made progress. While C, brilliant as it once was, has given us never ending problems with security and reliability. The software world is saturated anyways. It's time to revise rather than just layering new junk in chase of profit.
> This article does not aim to dismiss Zig. Its focus is on the fact that C never stopped evolving.
It didn't stop but it certainly slowed down to glacial pace. There's plenty of fundamental issues that will never be fixed.
That said. I wish the software world would just keep its cool and not commit to Rust so fast. Rust was the first in a trend of new low level languages. It snowballed and now we may not get to make an informed decision on how the future of low level programming should be. I personally like Zig a lot more. Unfortunately people seem to be neither adequately scared of complexity nor sufficiently impressed by simplicity.
Not a single mention of defer? There's no way I'll ever go back to writing goto towers.
Yes, I'm aware that some specific C toolchains have nonstandard extensions that accomplish the same thing, but if you lock yourself into one of those, the "Portability and Presence" section (and really, the first 20% of the article) goes out the window.
Did you not even try the original command? As you've now updated it (https://github.com/little-book-of/c/commit/43b0a89852a507bdd...), it is definitely not one simple flag since arm-linux-gnueabihf-gcc has to be installed from somewhere. It doesn't exist in a default installation of GCC that only targets the host, and you'll need to install a GCC version for every architecture you want to target.
the part where C syntax examples are shown misses the same examples in zig to really allow a comparison. i am already familiar with C. giving me a C example and telling me it's better than zig does not tell me anything. i'd need to see the equivalent zig example too.
> It includes some of the most advanced tools in computing
Half of them which shouldn’t be needed if the language didn’t let you shoot yourself in the foot in the first place.
> Transparency in Behavior
Undefined behavior has entered the chat
> Loop structures are clean and readable
If you like fiddling with i-variables and sizeof like foreach never happened.
> Error handling and optional results use simple, explicit patterns.
Proceeds and ignores the return code of fread(), leaving errors unhandled.
At this point I lost it as became more and more obvious it’s both AI slop and it’s ignoring the past 20 years of progress in programming languages. C may have its uses but jeez don’t pretend it is ergonomic.
Ah yes, the “portable” language where different implementations can’t even agree on how big an integer is. Don’t get me started about the “transparency in behavior” that’s not even close to how any modern computer works.
It’s hard to see this article as being written in good faith. We’re at the point that we are responding to low quality LLM outputs with low quality LLM retorts and voting them both to the front page because of feelings.
I'm at the point now where I simply stop reading the article once it has too many red flags, something that is happening increasingly often.
I don't enjoy reading AI slop but it feels worse when users of AI tools have chosen not to disclose the authors of these articles as Claude/ChatGPT/etc. Rather than being honest upfront, they choose to hide this fact.
I added some sentences at the top, so it wont waste people's time:
Some parts of this article were refined with help from LLMs to improve clarity and technical accuracy. These are just personal notes, but I would really appreciate feedback: feel free to share your thoughts, open an issue, or send a pull request!
If you prefer to read only fully human-written articles, feel free to skip this one.
> Some parts of this article were refined with help from LLMs to improve clarity and technical accuracy
Perhaps you should stick to writing about things you can write with clarity and and accuracy yourself instead of relying on an LLM to do it for you. Alternatively, properly cite and highlight what portions you used AI on/for from the outset as failure to do so reads at best as lazy slop and more often as intentional duplicity
As a fan and user of Zig I found the original post embarrassing, but chalked it up to the enthusiasm of a new user discovering the joy of something that clicked for them
Taking offense to that enthusiasm and generating this weirdly defensive and uninformed take is something else, though
> Cross-compilation looks like a standout feature in Zig, although C developers have been doing the same thing for decades. ... You can target an embedded ARM board or a RISC-V chip with one flag:
Disagree: Zig's cross-compilation support is better than anything else. For one, installing a toolchain for a different OS/arch combo is not necessarily so easy with C. For another, with Zig you can target an arbitrary Linux glibc version with a commandline argument. Without Zig's toolchain, [2] the best I've seen is to run within a Docker container with that glibc version installed.
[1] almost entirely because I think all new languages should have memory safety (via GC or borrow checking).
[2] I see people linking Rust programs with Zig's toolchain for this reason: https://github.com/rust-cross/cargo-zigbuild