It 100% is a big deal. I explained this in another comment [0].
> Question: "So after this change, is there way I can still simply call zig run or do I have to use a build.zig file?"
Andrew's answer: "No, this use case will regress."
This in fact literally states that "just" calling "zig run" won't be possible anymore, and heavily implies you'll need a build.zig file.
> This in fact literally states that "just" calling "zig run" won't be possible anymore,
This seems correct.
> and heavily implies you'll need a build.zig file.
This seems to not be the case.
No, I’m not. Respectfully, you’re responding to my point while admitting in your comment [0] that you don’t actually know.
If you read the relevant discussions, the conclusion, last time I checked, was that there’s going to be a build system requirement.
You’re making a lot of “assumptions” when you could just read the GitHub issue regarding this change, written by Andrew himself, titled “move @cImport to the build system” [0].
By the way, please note that I not only write Zig code almost daily, I’ve personally contributed to the Zig build system.
The idea that C programmers, C programmers, are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible.
The complexity has moved to a slightly different place. That's it.
What I find incredible about these takes is that they’re so removed from reality. It’s quite unfortunate how difficult it is to get a lot of programmers to evaluate things from the shoes of others.
I have firsthand experience trying to get fellow C programmers to try Zig (and Rust too), and it’s already extremely difficult as is. The three things that have helped me sell Zig has been the combination of (1) how easy it is to get up and running with it (no prerequisites or installs necessary) [0], (2) the C interop story (which was a selling point for me [1]), and (3) the very simple yet impressive and complete build process [0].
What’s interesting is that you call my point risible when, based on your response, it’s clear to me you don’t understand the audience we’re talking about.
For example, you say:
> because they have to copy-paste a build.zig gist to get started
Professional C programmers generally favor actually understanding what’s happening under the hood, so unlike, e.g., JavaScript or Python developers, suggesting they get started by copying and pasting build code they don’t understand is a nonstarter for a lot of C programmers. And understanding Zig’s build system doesn’t happen as quickly [1] as being able to use Zig directly. Even after writing a decent amount of Zig build code, I’ve had to, on a number of occasions, go read the Zig build system code to understand how something is implemented (e.g., how it deals with certain paths, peculiarities of the dependency system, caching semantics, etc.)—if I had to figure out the build system before I was able to get started with Zig and be productive, I would’ve never taken it seriously.
There’s a reason why Zig has been marketed as a compiler that can also server as a drop-in replacement for GCC/Clang. What you’re effectively saying is that this main selling point doesn’t matter even though that’s been one of the main things that makes Zig attractive to C programmers. Incredible.
Really, I think what C developers want is a modern, opinionated tooling solution a la cargo. If the Zig build system can deliver that (plus the much better ergonomics of the language itself), I think it could be very compelling.
I’m sick of Make, CMake, Nix flakes, Docker, manually bundling specific arm cross toolchains, etc. If I can send someone a Zig + C project and the zig.build Just Works, I’m all for it.
- You're used to the way it works now, and don't like that it's changing
- The build system is woefully underdocumented (understandable, since it's new and hasn't stabilized, but it's not a good thing), and you're conflating that with the system being hard to understand, which it isn't.
- You're combining these things, and your inflated sense of how well you know every C programmer in existence, into a claim which, again, I consider risible.
Because you're saying things like this:
> There’s a reason why Zig has been marketed as a compiler that can also serve as a drop-in replacement for GCC/Clang. What you’re effectively saying is that this main selling point doesn’t matter even though that’s been one of the main things that makes Zig attractive to C programmers. Incredible.
Which is a bizarre thing to derive from what I said, and is also absurd. Andrew wants Zig to be the best way to build C, always has, and he's the one responsible for making it as good as it is. His goals there haven't changed, what's changed is how he intends to provide that.
Now, you can claim, and you have, that he's going to make it much worse in the process. But your reasoning for saying this is thin and I disagree with that premise completely.
What's happening is that C imports are moving to the build system, instead of being a compiler builtin. It's part of making LLVM and libclang optional for programs which don't use it, but the use case of building C programs, and integrating C libraries with Zig programs, remains a central design goal.
The build system is relatively new, and a lot of things which were originally independent subcommands are being consolidated into the build system.
There's a sort of ambient impression that "Zig won't support C anymore" floating around, I'm not sure from your post whether you have that impression or not, but it isn't even vaguely true.
It just means that importing C libraries will be a build step, and not something you write directly into the relevant source code. This is not a big deal.