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.

> This is not the first controversial change I have made to the Zig project, and it won't be the last. I have a vision, and I know how to execute it. People are often surprised by what Zig has accomplished, and they wonder why other projects have not done what Zig does. Well, you are seeing the magic right now. I ignore the peanut gallery and do what I know is right, while taking care of my users' needs at the same time. If you don't understand now, you will understand once this plan unfolds. By that time it will seem obvious in hindsight.

He's probably brillant and all but this ... feels like hubris.

What he should have done is announce a project at the same time that will maintain the current developer experience, even if that project is not part of the zig foundation. The developer doesn't care about how he builds zig. They want 1) download 2) use. It doesn't matter from where. If today it's directly from zig, and tomorrow it's from elsewhere to download a combined package, that 's all the devs needed to hear.

I tried D years ago (at least 5 years ago, I think), but I don’t remember experimenting with the C interop.

Your explanation sounds intriguing though. And a couple pretty smart folks I respect have talked about D too. So thanks for bringing it up. I’m going to make some time to experiment with it again some time soon.

> Is that as good as Rust?

Franky, although I don’t have firsthand experience with D, your explanation and example make the D C interop experience sound actually better than Rust’s. It seems more similar to Zig.

Package managers are a lot more complex than people realize. Every attempt I've seen in every language has significant lacks for common real world cases.

Most commonly they assume all the world is their language. Very commonly they want to take over all package management but don't have a good easy story for working with the OS package manager (I know Windows doesn't really have a package manager - but you still need to interoperate with it!). Those are big issues anyone in a complex project will face in the real world, there are also lots of little warts that will bite you.

Yes package managers are nice on your trival project. However they all get in the way in your non-complex project - some more than others.

The actual build system functionality is 'just' an extension to the stdlib.

It can compile almost any dependency on demand, even doing cross-compilation. And it's used by at least Microsoft and Google.

I’ve been able to convince C programmers to try out and use Zig just due to this unique ability alone, and to be clear, getting C programmers to seriously consider any language other than C is generally very difficult!

Having to consider another build system (with its own semantics), which the current Zig experience doesn’t require, changes the experience much more substantially than I think the Zig team realizes.

You’re oversimplifying what’s actually a significant change.

Right now, I can do the following:

1. Download a prebuilt Zig release [0], on a fresh computer (zero prerequisites).

2. Implement a C library foo via foo.h and foo.c.

3. Compile foo.c into an object file foo.o via `zig cc`, using standard GNU-compatible compiler flags, for virtually any of the common (and even not-so-common) compilation targets.

4. Implement a Zig program bar via bar.zig.

5. Directly import foo.h into bar.zig via `@cImport` and use the C API as if it was Zig code.

6. Compile bar.zig and foo.o into a statically-linked executable baz via `zig build-exe`, for virtually any of the common (and even not-so-common) compilation targets.

No knowledge of the Zig build system and its semantics necessary. This is one of the most attractive aspects of Zig for a C programmer. I’ve gone through these exact steps with C programmers who thought Zig seemed interesting in theory but just didn’t want to have to learn a new ecosystem, build system, etc. The moment I showed them how quickly they could get up and running with Zig (and test it out with C code), without even having to install anything, it suddenly was impressive enough to experiment with.

The build system requirement may seem minor if you’re already a Zig programmer, but it’s massive if you want to attract C systems programmers.

[0]: https://ziglang.org/download

As it is currently described, @import of C will require build.zig and specific configuration therein.

    translateSpecialCaseNames(.{
        .{ .src = "ABOMINATIONCase", .dst = "case" },
        .{ .src = "NAMESPACED_PascalCase", .dst = "pascalCase" },
    });

I think its fair criticism that as a beginner, you don't actually want to deal with build.zig or even understand it. You just want to write some code and run it and look at build.zig after you gained some familiarity with the language itself.

I just prefer using Zig on emacs with the built-in eglot LSP client. You just tell it where you installed ZLS (and it won't do magic to get it for you) and off you go. It's the same level of support as with VS Code. If you're not new to emacs, maybe consider that (otherwise emacs may be too much of a rabbit hole :)).