Zig is so cool, C is cooler
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] I see people linking Rust programs with Zig's toolchain for this reason: https://github.com/rust-cross/cargo-zigbuild
>You can target an embedded ARM board or a RISC-V chip with one flag:
gcc main.c --target=arm-linux-gnueabihf -o app
I have read both articles (this and zig-cool), and I regret the time wasted.
IMO, both articles fail to deliver on their titles :(
Both fail to list really cool parts, and both reiterate same arguments several times. This one even looks like an LLM output, but I'm not sure.
I like neither C nor zig
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.
The main reason why C is used everywhere is because the C ABI is the de facto ABI.
This is why Zig was smart to have first party support for C libs.
In fact the fact Zig pointer types are more precise, it allows imported C libs to be more correct than the original C.
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.
gcc main.c --target=arm-linux-gnueabihf -o app
this is definitely wrong, the correct way is to use arm-linux-gnueabihf-gcc main.c instead, there is no such flag called --target per se
Obviously the answer to https://nilostolte.github.io/tech/articles/ZigCool.html (discussed in https://news.ycombinator.com/item?id=45852328 ; currently both at first page alongside each other).
Something I didn't see mentioned are alternative compilers like tcc that provide ~9x faster compilation - very useful during development etc
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.
> 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.
> 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.
This feels wrong.
> 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.
This is like that situation where a kid goes up to the dad who abandoned him and says, "You have given me nothing! I had to do everything myself."
And the dad says back, "By giving you nothing I have given you everything. Look at the tough guy you have become!"
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.
What a dumb writeup.
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.