Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Macro Reflection in Zig

jstrieb.github.io

Post reply on HN
Print view View original

21–30 of 139 posts

Re: C Macro Reflection in Zig

#21

Post by Cloudef »

jay-barronville wrote: post #14
skywal_l wrote: post #2

@cImport is on the chopping block though [0]. You will still be able to import c files but it will require a little more work. This is because they want this functionality out of the language so they can remove libclang dependency. [0]: https://github.com/ziglang/zig/issues/20630

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 I respect Andrew a lot (I…

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.

Re: C Macro Reflection in Zig

#22

Post by jll29 »

jay-barronville wrote: post #14
skywal_l wrote: post #2

@cImport is on the chopping block though [0]. You will still be able to import c files but it will require a little more work. This is because they want this functionality out of the language so they can remove libclang dependency. [0]: https://github.com/ziglang/zig/issues/20630

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 I respect Andrew a lot (I…

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

[2] ICU - https://icu.unicode.org

[3] SDS - https://github.com/antirez/sds

[4] GLib - https://docs.gtk.org/glib/struct.String.html

Re: C Macro Reflection in Zig

#23

Post by jay-barronville »

Cloudef wrote: post #21
jay-barronville wrote: post #14

Earlier quoted context omitted.

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 I respect Andrew a lot (I…

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 preproces…

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.

Re: C Macro Reflection in Zig

#24

Post by flohofwoe »

jll29 wrote: post #22
jay-barronville wrote: post #14

Earlier quoted context omitted.

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 I respect Andrew a lot (I…

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 (s…

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.

Re: C Macro Reflection in Zig

#25

Post by flohofwoe »

jay-barronville wrote: post #23
Cloudef wrote: post #21

Earlier quoted context omitted.

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 preproces…

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…

> 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).

Re: C Macro Reflection in Zig

#26

Post by jay-barronville »

flohofwoe wrote: post #25
jay-barronville wrote: post #23

Earlier quoted context omitted.

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…

> 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…

> 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?!?”

Re: C Macro Reflection in Zig

#27

Post by Laremere »

jay-barronville wrote: post #14
skywal_l wrote: post #2

@cImport is on the chopping block though [0]. You will still be able to import c files but it will require a little more work. This is because they want this functionality out of the language so they can remove libclang dependency. [0]: https://github.com/ziglang/zig/issues/20630

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 I respect Andrew a lot (I…

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-161... https://github.com/ziglang/zig/issues/16270#issuecomment-161...

Re: C Macro Reflection in Zig

#28

Post by fxtentacle »

jll29 wrote: post #22
jay-barronville wrote: post #14

Earlier quoted context omitted.

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 I respect Andrew a lot (I…

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 (s…

vcpkg + CMake ?

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

Re: C Macro Reflection in Zig

#29

Post by flohofwoe »

fxtentacle wrote: post #28
jll29 wrote: post #22

Earlier quoted context omitted.

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 (s…

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

Such a setup includes two complex tools from two different parties plus a different C/C++ compiler toolchain per platform and platform SDKs (at least GCC, Clang (plus its Apple flavour) and MSVC). All those tools working together flawlessly at any given time is a minor miracle.

In Zig all those things are in the same toolchain install, which is a a single executable plus a bunch of platform-system-headers and -libraries, all under a single version number and trivially downloadable as a zip archive which works right after unzipping without setting up paths or running an 'installer'.

Re: C Macro Reflection in Zig

#30

Post by brabel »

jay-barronville wrote: post #14
skywal_l wrote: post #2

@cImport is on the chopping block though [0]. You will still be able to import c files but it will require a little more work. This is because they want this functionality out of the language so they can remove libclang dependency. [0]: https://github.com/ziglang/zig/issues/20630

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 I respect Andrew a lot (I…

> 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

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

C libraries (header files) can be compiled to D and then used as D modules as well, see https://github.com/jacob-carlborg/dstep

Is that as good as Rust?

Post reply on HN