https://www.bellard.org/tcc/

> 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

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.

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.

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

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.

  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

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.

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.

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.

And the dad says back, "By giving you nothing I have given you everything. Look at the tough guy you have become!"

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.

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.