What specifically did you find dumb about this?

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

for newer chips or some vendor-optimized-purpose etc, you have to rely on vendor's SDKs, zig can not help there either.

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?

If you ever use LLMs for "technical accuracy" again, maybe actually test things on the command line.

Sorry for all the negativity. I added some clarifications, but it might have been a bit too late.

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.

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

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.

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.

very well

> 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

Taking offense to that enthusiasm and generating this weirdly defensive and uninformed take is something else, though

It's not "weirdly defensive and uninformed" to question the value of posting a bunch of inaccurate LLM slop, especially without any disclosures.

If you're pro-AI, you should be against this too, before these errors get used as training data.

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.

What's a goto tower?

(Repeating sibling post, `defer` is in the works for C as well)

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

C's ecosystem is the opposite. It is modular, built from separate tools like GCC, ld, Make, and apt. You compose them externally.

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.

Which parts did you feel were missing or didn't live up to the title? What kind of points or examples would have made it feel more worthwhile to you?

  gcc main.c --target=arm-linux-gnueabihf -o app

just got updated with some clarity

> *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!*

https://github.com/little-book-of/c/commit/43b0a89852a507bdd...

https://github.com/little-book-of/c/commit/349d475a5922cf005...

It might also be someone used to a system which symlinks "gcc" to clang for compatibility (IIRC, that's the case at least on OS X).

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.