Live data from Hacker News

C Macro Reflection in Zig

jstrieb.github.io

51–60 of 139 posts

Re: C Macro Reflection in Zig

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

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

Re: C Macro Reflection in Zig

#52
post #21

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…

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

Re: C Macro Reflection in Zig

#53

Earlier quoted context omitted.

Tbf, when coming from the C/C++ ecosystem, these types of problems are 'just another Tuesday' (especially for cross-platform projects and the official VSCode C/C++ extension).

This is part of the reason why I don't use VSCode for C(++). Jetbrains Clion seems to be the best IDE for those languages, with Visual Studio (the full fat one, costing a grand, as the free version lacks a bunch of features) as a close second, depending on what platform you're developing for. VSCode is great when it works, but in cases like these it quickly becomes obvious that it's a hodge-podge of tools glued toget…

I'm not one to defend VSC as such, but I do think it's fair to mention that a lot of the Zig issues have been directly with the Zig LSP (zls) and not necessarily with any specific editor extension. Though I suppose some of it may be worse with VSC as it's often been rather important to keep both your Zig and zls versions up-to-date and synchronized. I'm not sure how that happens with the VSC extension, but if it auto-updates your zls version (which it probably does) then it may race ahead of your Zig version which might cause problems.

Re: C Macro Reflection in Zig

#54

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…

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

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.

Re: C Macro Reflection in Zig

#55
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

> remove libclang

So `zig cc` will have to go as well ? I was under the impression Zig as a drop-in C (cross-)compiler was one of its main selling points.

Re: C Macro Reflection in Zig

#56
post #54

Earlier quoted context omitted.

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

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

Reading that comment for the first time just now, and I love that. More power to them.

Re: C Macro Reflection in Zig

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

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.

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.

Re: C Macro Reflection in Zig

#58
post #54

Earlier quoted context omitted.

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

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

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.

Re: C Macro Reflection in Zig

#59

I really want to like zig, but I've just had some annoying problems with it, most of which I think are just a result of it not being in 1.0 yet. For example, the recommended way to start a project, with `zig init`, has a load of code that I really don't need when I just want a bare project to get started. I only recently found out that you can just `zig build-exe filename.zig` and skip the whole init part. Also I've…

Tbf, when coming from the C/C++ ecosystem, these types of problems are 'just another Tuesday' (especially for cross-platform projects and the official VSCode C/C++ extension).

Note for people wanting to use vscode for c or c++ development. The clangd extension* is provides much better code completion and jump to definition compared to the default c/c++ extension.

* https://marketplace.visualstudio.com/items?itemName=llvm-vs-...

Re: C Macro Reflection in Zig

#60
post #54

Earlier quoted context omitted.

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

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

Don Quixote or St. George? Only time will tell. Meanwhile the code works.
Post reply on HN