4 ms·

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 c

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
    I truly wish that Rust would steal this from Zig, but I haven't heard any actual interest in it from the project. Oh well. I think it's a real missed opportunity. https://crates.io/crates/cargo-zigbuild https://crates.io/crates/cargo-zigbuild exists though.
jeltz 2y ago
Having worked with Rust I would say that is bad. @cImport is way better than the C introp in Rust.
throwawaymaths 2y ago
You will probably be able to do it from the command line too (for build-exe, run, etc).

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
  I truly wish that Rust would steal this from Zig, but I haven't heard any actual interest in it from the project. Oh well. I think it's a real missed opportunity. https://crates.io/crates/cargo-zigbuild https://crates.io/crates/cargo-zigbuild exists though.

jeltz 2y ago

Having worked with Rust I would say that is bad. @cImport is way better than the C introp in Rust.

throwawaymaths 2y ago

You will probably be able to do it from the command line too (for build-exe, run, etc).