6 ms·

While I understand the reasoning, I think this is one of the most disappointing decisions by the Zig team. One of the main reasons I took Zig seriously was the

While I understand the reasoning, I think this is one of the most disappointing decisions by the Zig team. One of the main reasons I took Zig seriously was their C interop story—as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), I was pretty much sold on Zig when I was able to, in a total of < 3-ish hours, (1) implement a complete Zig wrapper over a C library I wrote without introducing any overhead, (2) build a Zig program using the wrapper, and (3) cross-compile the program, statically, producing single binaries for 5 different targets…Linux (amd64, arm64), macOS (amd64, arm64), and Windows (amd64), ALL from one laptop using a single Zig executable and some simple flags. This was C interop and productivity I’ve never experienced before. I respect Andrew a lot (I think he’s pretty brilliant), so I hope this turns out to not be as bad as I think it’ll be for those of us who love Zig for what brings to the table for programmers who are biased toward C.

flohofwoe 2y ago
The translate-c build system step and wrapping the output in a Zig module is currently about 10 lines in build.zig, and I guess this could be reduced further by merging those two steps into a single step. I think that's an acceptable compromise. Especially for C libraries which require configuration via preprocessor defines or compilation flags, the build.zig way is a lot cleaner than the @-builtins that are currently used (IMHO).
Cloudef 2y ago
How I see is that the only thing that changes is that you can't do @importC anymore. You'll instead do something in build.zig that produces a module which you can then addImport("my-c-lib", generated_module); which you then @import("my-c-lib"); in your zig code as you would with @cImport. This does not seem bad in paper. One thing that does worsen with this is that in @cImport you could also comptime define preprocessor macros which was really cool, now that would have to be handled by build.zig I guess.
- jay-barronville 2y ago
  This makes the experience more similar to Rust (which I don’t think is bad—it’s just not as unique, smooth, and impressive as the current Zig experience). 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.
  - flohofwoe 2y ago
    > This makes the experience more similar to Rust The big difference to the Rust ecosystem (or rather the 'cc' crates.io package which AFAIK is the current standard solution) is that there will be a Clang toolchain package with integrated cross-compilation headers and libraries that is used across all platforms instead of relying on a "platform C/C++ compiler toolchain" - which is the actually brittle part: different compilers, linkers and platform SDKs used on different platforms). Ideally that same integrated Clang toolchain package used and provided by Zig could also be used by Rust to improve the C/C++/ObjC cross-compilation situation (similar to how the Zig toolchain is sometimes already used for this purpose).
    - jay-barronville 2y ago
      > The big difference to the Rust ecosystem (or rather the 'cc' crates.io package which AFAIK is the current standard solution) is that there will be a Clang toolchain package with integrated cross-compilation headers and libraries that is used across all platforms instead of relying on a "platform C/C++ compiler toolchain" - which is the actually brittle part: different compilers, linkers and platform SDKs used on different platforms). Yes, this is a very good point. Zig remains unique and impressive in that sense. The fact that Zig compiles the correct libc and other system libraries on demand is actually another one of those, “How come no other language considered doing this before Zig?!?”
    - steveklabnik 2y ago
jll29 2y ago
This sounds amazing, and it's great that tooling is so strong of some "new kids on the block" (Zig, Rust), even better than C. With hindsight, it is strange that the C community, with all the people and money behind it (and what scale!) never even managed to build a proper packaging manager (okay, there's now Conan, but that came from Python guys). But then, there even still isn't a perfect C string library around (something that would combine GLib, SDS, ICU, say, and then standardize it in C2038). [1] Hanson's C: Interfaces & Implementations (CII) - Str: https://cii.s3.amazonaws.com/book/pdf/quickref.pdf https://cii.s3.amazonaws.com/book/pdf/quickref.pdf [2] ICU - https://icu.unicode.org https://icu.unicode.org [3] SDS - https://github.com/antirez/sds https://github.com/antirez/sds [4] GLib - https://docs.gtk.org/glib/struct.String.html https://docs.gtk.org/glib/struct.String.html
- flohofwoe 2y ago
  The interesting thing is that the Zig build system could be implemented in a C/C++ compiler without any language changes. All that's needed is that (for instance) Clang would have a new option `clang build` which looks for a build.c/cpp file, compiles that into an executable and runs it. The actual build system functionality is 'just' an extension to the stdlib.
  - pjmlp 2y ago
    It could, but then it would be tied to that specific compiler and the platforms it supports. So is the mess of ISO defined languages, where compiler toolchains are an abstract concept. Also a good point to note that OpenGroup and POSIX never bothered to standardise UNIX package management.
    - flohofwoe 2y ago
      Yeah, just Clang doing its own thing would be useless. It would have to go through the C and C++ committees, at least for the stdlib parts (and this is basically the show stopper for the idea unfortunately).
- fxtentacle 2y ago
Laremere 2y ago
See these posts on the LLVM issue by Andrew. They clearly state that this functionality isn't going anywhere, just the method of achieving said functionality is changing: https://github.com/ziglang/zig/issues/16270#issuecomment-1615388680 https://github.com/ziglang/zig/issues/16270#issuecomment-161... https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161...
- ajnin 2y ago
  Not involved with Zig at all, but this comment is a bit concerning : > 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.
  - JasonSage 2y ago
    Reading that comment for the first time just now, and I love that. More power to them.
  - BiteCode_dev 2y ago
    Or very high confidence backed up by experience and skill, expressed through an honest personality. In a world of humble bragging and cheap talk, I find it refreshing.
  - carapace 2y ago
    Don Quixote or St. George? Only time will tell. Meanwhile the code works.
  - acedTrex 2y ago
    Wow, that actually makes me want to look into zig a lot more. so many projects, rust included, get bogged down in design by committee and half baked decisions that please no one.
brabel 2y ago
> as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), Have you tried D? It can import C files as if they were D modules: https://dlang.org/spec/importc.html https://dlang.org/spec/importc.html Basically, if there's a `hello.c` file next to your D file, you simply import it with: import hello And use the functions it provides. You can also import only a subset of it, of course: import hello: square; Or rename the import: import hi = hello; The C stdlib is exposed by D's stdlib as if it were a D library: https://dlang.org/phobos/core_stdc_assert_.html https://dlang.org/phobos/core_stdc_assert_.html C libraries (header files) can be compiled to D and then used as D modules as well, see https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/dstep Is that as good as Rust?
- jay-barronville 2y ago
  > Have you tried D? 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.
  - brabel 2y ago
    I think the feature that allows importing c, called "importC", is newer than 5 years. I think they may have "copied" it from Zig :D they definitely are trying to not "fall behind" Zig and keep making the language better. With DMD, you can cross compile just as with Zig, but only to object files as the linker is not multi-platform... so I am experimenting with using Zig's linker to "finish" the job. Unfortunately, Zig is not being able to link Phobos, the D stdlib, for reasons I don't understand yet.
1980phipsi 2y ago
D has made some improvements on C interop with importC, if you want to check that out: https://dlang.org/spec/importc.html https://dlang.org/spec/importc.html
throwawaymaths 2y ago
What's the problem? @cImport is becoming just @import.
- kbolino 2y ago
  @cImport works without build.zig and even with build.zig requires no special configuration (ignoring linking). As it is currently described, @import of C will require build.zig and specific configuration therein.
  - jeltz 2y ago
    And form my experience from Rust that is much less ergonomic. Maybe Zig will do it better than Rust but who knows?
  - samatman 2y ago
    build.zig is on its way to being essential. I consider that an appropriate development. Binaries need to be built, this should be integrated with the rest of the system in any modern language. It's not incompatible with using something like CMake or Ninja either, it just puts certain responsibilities inside of build.zig. Where they belong.
  - throwawaymaths 2y ago
    I don't think that's the case. In general you can set up @import modules from the command line, and I'm not 100% sure but I think build.zig generally just templates a command line call anyways.
    - kbolino 2y ago
      I don't think this DSL is finalized yet, but you can see on a linked issue what the build.zig to support @import of C looks like on nightly: const translate_c = b.addTranslateC(.{ .root_source_file = b.path("src/c.h"), .target = target, .optimize = optimize, }); exe.root_module.addImport("c", translate_c.createModule()); https://github.com/ziglang/zig/issues/20648 https://github.com/ziglang/zig/issues/20648

flohofwoe 2y ago

The translate-c build system step and wrapping the output in a Zig module is currently about 10 lines in build.zig, and I guess this could be reduced further by merging those two steps into a single step. I think that's an acceptable compromise. Especially for C libraries which require configuration via preprocessor defines or compilation flags, the build.zig way is a lot cleaner than the @-builtins that are currently used (IMHO).

Cloudef 2y ago

How I see is that the only thing that changes is that you can't do @importC anymore. You'll instead do something in build.zig that produces a module which you can then addImport("my-c-lib", generated_module); which you then @import("my-c-lib"); in your zig code as you would with @cImport. This does not seem bad in paper. One thing that does worsen with this is that in @cImport you could also comptime define preprocessor macros which was really cool, now that would have to be handled by build.zig I guess.

jay-barronville 2y ago
This makes the experience more similar to Rust (which I don’t think is bad—it’s just not as unique, smooth, and impressive as the current Zig experience). 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.
- flohofwoe 2y ago
  > This makes the experience more similar to Rust The big difference to the Rust ecosystem (or rather the 'cc' crates.io package which AFAIK is the current standard solution) is that there will be a Clang toolchain package with integrated cross-compilation headers and libraries that is used across all platforms instead of relying on a "platform C/C++ compiler toolchain" - which is the actually brittle part: different compilers, linkers and platform SDKs used on different platforms). Ideally that same integrated Clang toolchain package used and provided by Zig could also be used by Rust to improve the C/C++/ObjC cross-compilation situation (similar to how the Zig toolchain is sometimes already used for this purpose).
  - jay-barronville 2y ago
    > The big difference to the Rust ecosystem (or rather the 'cc' crates.io package which AFAIK is the current standard solution) is that there will be a Clang toolchain package with integrated cross-compilation headers and libraries that is used across all platforms instead of relying on a "platform C/C++ compiler toolchain" - which is the actually brittle part: different compilers, linkers and platform SDKs used on different platforms). Yes, this is a very good point. Zig remains unique and impressive in that sense. The fact that Zig compiles the correct libc and other system libraries on demand is actually another one of those, “How come no other language considered doing this before Zig?!?”
  - steveklabnik 2y ago

jll29 2y ago

This sounds amazing, and it's great that tooling is so strong of some "new kids on the block" (Zig, Rust), even better than C. With hindsight, it is strange that the C community, with all the people and money behind it (and what scale!) never even managed to build a proper packaging manager (okay, there's now Conan, but that came from Python guys). But then, there even still isn't a perfect C string library around (something that would combine GLib, SDS, ICU, say, and then standardize it in C2038). [1] Hanson's C: Interfaces & Implementations (CII) - Str: https://cii.s3.amazonaws.com/book/pdf/quickref.pdf https://cii.s3.amazonaws.com/book/pdf/quickref.pdf [2] ICU - https://icu.unicode.org https://icu.unicode.org [3] SDS - https://github.com/antirez/sds https://github.com/antirez/sds [4] GLib - https://docs.gtk.org/glib/struct.String.html https://docs.gtk.org/glib/struct.String.html

flohofwoe 2y ago
The interesting thing is that the Zig build system could be implemented in a C/C++ compiler without any language changes. All that's needed is that (for instance) Clang would have a new option `clang build` which looks for a build.c/cpp file, compiles that into an executable and runs it. The actual build system functionality is 'just' an extension to the stdlib.
- pjmlp 2y ago
  It could, but then it would be tied to that specific compiler and the platforms it supports. So is the mess of ISO defined languages, where compiler toolchains are an abstract concept. Also a good point to note that OpenGroup and POSIX never bothered to standardise UNIX package management.
  - flohofwoe 2y ago
    Yeah, just Clang doing its own thing would be useless. It would have to go through the C and C++ committees, at least for the stdlib parts (and this is basically the show stopper for the idea unfortunately).
fxtentacle 2y ago

Laremere 2y ago

See these posts on the LLVM issue by Andrew. They clearly state that this functionality isn't going anywhere, just the method of achieving said functionality is changing: https://github.com/ziglang/zig/issues/16270#issuecomment-1615388680 https://github.com/ziglang/zig/issues/16270#issuecomment-161... https://github.com/ziglang/zig/issues/16270#issuecomment-1616115039 https://github.com/ziglang/zig/issues/16270#issuecomment-161...

ajnin 2y ago
Not involved with Zig at all, but this comment is a bit concerning : > 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.
- JasonSage 2y ago
  Reading that comment for the first time just now, and I love that. More power to them.
- BiteCode_dev 2y ago
  Or very high confidence backed up by experience and skill, expressed through an honest personality. In a world of humble bragging and cheap talk, I find it refreshing.
- carapace 2y ago
  Don Quixote or St. George? Only time will tell. Meanwhile the code works.
- acedTrex 2y ago
  Wow, that actually makes me want to look into zig a lot more. so many projects, rust included, get bogged down in design by committee and half baked decisions that please no one.

brabel 2y ago

> as someone who loves C and dislikes almost every implementation of C interop and FFI I’ve used in other languages (Rust is a notable exception to this), Have you tried D? It can import C files as if they were D modules: https://dlang.org/spec/importc.html https://dlang.org/spec/importc.html Basically, if there's a `hello.c` file next to your D file, you simply import it with: import hello And use the functions it provides. You can also import only a subset of it, of course: import hello: square; Or rename the import: import hi = hello; The C stdlib is exposed by D's stdlib as if it were a D library: https://dlang.org/phobos/core_stdc_assert_.html https://dlang.org/phobos/core_stdc_assert_.html C libraries (header files) can be compiled to D and then used as D modules as well, see https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/dstep Is that as good as Rust?

jay-barronville 2y ago
> Have you tried D? 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.
- brabel 2y ago
  I think the feature that allows importing c, called "importC", is newer than 5 years. I think they may have "copied" it from Zig :D they definitely are trying to not "fall behind" Zig and keep making the language better. With DMD, you can cross compile just as with Zig, but only to object files as the linker is not multi-platform... so I am experimenting with using Zig's linker to "finish" the job. Unfortunately, Zig is not being able to link Phobos, the D stdlib, for reasons I don't understand yet.

1980phipsi 2y ago

D has made some improvements on C interop with importC, if you want to check that out: https://dlang.org/spec/importc.html https://dlang.org/spec/importc.html

throwawaymaths 2y ago

What's the problem? @cImport is becoming just @import.

kbolino 2y ago
@cImport works without build.zig and even with build.zig requires no special configuration (ignoring linking). As it is currently described, @import of C will require build.zig and specific configuration therein.
- jeltz 2y ago
  And form my experience from Rust that is much less ergonomic. Maybe Zig will do it better than Rust but who knows?
- samatman 2y ago
  build.zig is on its way to being essential. I consider that an appropriate development. Binaries need to be built, this should be integrated with the rest of the system in any modern language. It's not incompatible with using something like CMake or Ninja either, it just puts certain responsibilities inside of build.zig. Where they belong.
- throwawaymaths 2y ago
  I don't think that's the case. In general you can set up @import modules from the command line, and I'm not 100% sure but I think build.zig generally just templates a command line call anyways.
  - kbolino 2y ago
    I don't think this DSL is finalized yet, but you can see on a linked issue what the build.zig to support @import of C looks like on nightly: const translate_c = b.addTranslateC(.{ .root_source_file = b.path("src/c.h"), .target = target, .optimize = optimize, }); exe.root_module.addImport("c", translate_c.createModule()); https://github.com/ziglang/zig/issues/20648 https://github.com/ziglang/zig/issues/20648