[ldelossa]

I'm surprised that the reason I'm mostly interested in Zig is not mentioned.

This is C interop.

I work with C quite a bit and I enjoy it, however writing a large project in C can be tiresome.

Having an option like Zig which can import C headers and call C functions without bindings is pretty attractive, especially when you want to write something a big larger but still stay in C world.

[workethics]

Not only that, but zig makes linking against old glibc versions easy. For example, to make an x86_64 linux build linked against glibc 2.9 when using zig build all you have to do is pass:

  -Dtarget=x86_64-linux-gnu.2.9

[GordonS]

Damn, that's a magnificent feature! Maybe I should have another look at Zig...

[TDiblik]

Hi, why is this feature interesting/important? (Coming from [uneducated] webdeveloper with interest for systems/embedded programming)

[beefcafe]

This is a killer feature for CTFs/OSCP/etc and why I started using it.

[ziml77]

The thing that's espcially nice about that interop is that Zig includes its own C compiler. That eliminates the pain of having a build script locate an installed C compiler and figure out what options should be passed to it.

[lost_tourist]

Why would I use zig c compiler in place of gcc or clang? Mainly for zig interactivity or does it have some advantage other than that over the aforementioned compilers?

[TUSF]

Zig's C/C++ compiler is just clang, but with header files for most major platforms included, and sane defaults, so there's no hassle getting it it to cross-compile. Some companies have been using Zig solely for an easier to use clang.

[lost_tourist]

Ah I see, thanks for your answer!

[bitshiffed]

I love this part about zig too. It definitely makes interop with, or gradual migration from, C, much easier.

It's also the source of my major problem with zig. It doesn't have its own ABI [1].

So, if for example, you want to write a library in zig, to be used by others from zig, they must build your library with their project. That may not be an issue for smaller things; but for a large library I'd really like consumers to be able to pull in a binary with just a definition (header) file. Since zig uses the C ABI, that would currently mean translating everything to and from C at the binary interface, and losing all ziggyness in the process.

[1] https://github.com/ziglang/zig/issues/3786

[esjeon]

C-interop is pretty perfect for most usecases. The only trouble I had was that, since command line arguments are converted to slices in Zig, I have to convert them back to null-terminated strings whenever I call C functions using any of the arguments. Nothing difficult but slightly painful.

[billfruit]

What about c++ interop?

[Conscat]

You can call internal and external linkage C++ functions from Zig, but you can't do anything interesting like specialize templates or evaluate constexpr functions.

[Fiahil]

C interop is not as much a "killer feature" as it used to be. When you deal with data science, web and other similar domains, reading and writing JSON ergonomically is much more important than being able to call a C function directly. It's just a nice-to-have.

[afdbcreid]

Yeah, but when you're doing systems programming (which Zig aims at if I understand correctly), easy interop with C is much more important than easy JSON marshalling.