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

81–90 of 139 posts

Re: C Macro Reflection in Zig

#81

Post by samatman »

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

It will require a little more work in a trivial way, but not in a meaningful way.

What's happening is that C imports are moving to the build system, instead of being a compiler builtin. It's part of making LLVM and libclang optional for programs which don't use it, but the use case of building C programs, and integrating C libraries with Zig programs, remains a central design goal.

The build system is relatively new, and a lot of things which were originally independent subcommands are being consolidated into the build system.

There's a sort of ambient impression that "Zig won't support C anymore" floating around, I'm not sure from your post whether you have that impression or not, but it isn't even vaguely true.

It just means that importing C libraries will be a build step, and not something you write directly into the relevant source code. This is not a big deal.

Re: C Macro Reflection in Zig

#82

Post by jeltz »

flohofwoe wrote: post #76
kasajian wrote: post #69

Earlier quoted context omitted.

Sounds like damage control. I have to say, for a brilliant guy, andrewrk knows nothing about marketing. The fact that the Zig project can make this significant of a change to their core-value because "trust me i know what I'm doing", makes it impossible (for now) to rely on this in any type of a widely-deployed Enterprise setting. This just made the highly risky move of moving to Zig make it darn near impossible. Wha…

Unfortunately there's a lot of people on the internet who haven't even used Zig nor plan to use it anytime in the future and who just enjoy to create drama by amplifying any decision with a hint of controversy around it (also see the 'unused variables are errors' drama which turned out to be a non-issue after it was actually implemented). Unrelated to Zig, it's the exact same thing with "WASM can't access the DOM" bt…

The LLVM divorce has also gotten criticism since it first was announced and we have so far not seen any complete solution. Maybe we will land in one but if people did not voice their concerns there is no reason to think such a solution would be found.

Re: C Macro Reflection in Zig

#83

Post by jeltz »

kbolino wrote: post #78
throwawaymaths wrote: post #51

Earlier quoted context omitted.

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

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

And form my experience from Rust that is much less ergonomic. Maybe Zig will do it better than Rust but who knows?

Re: C Macro Reflection in Zig

#84

Post by samatman »

kbolino wrote: post #78
throwawaymaths wrote: post #51

Earlier quoted context omitted.

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

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

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.

Re: C Macro Reflection in Zig

#85

Post by samatman »

jeroenhd wrote: post #35
voidUpdate wrote: post #6

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…

I have the same issue. It's hard to say if the tooling is working but incomplete, or if the tooling doesn't work for some reason. I can get syntax highlighting to work, but basic variable autocomplete doesn't, so I'm guessing the language server ran into some kind of issue. I really want to get started with Zig but I don't want to go back to the age of nano/edit.com for learning a new language. Zig is complex enough…

For what it's worth, outside of some outstanding issues with comptime (which are genuinely difficult, if ultimately solvable), I've found autocomplete, go-to-definition, and the other LSP semantic tools, to work fine in vs-code.

You could hop on the Discord and get some help with your configuration if you'd like. All things Zig are somewhat underdocumented currently, that could use some polish for sure.

Re: C Macro Reflection in Zig

#86

Post by kasajian »

flohofwoe wrote: post #76
kasajian wrote: post #69

Earlier quoted context omitted.

Sounds like damage control. I have to say, for a brilliant guy, andrewrk knows nothing about marketing. The fact that the Zig project can make this significant of a change to their core-value because "trust me i know what I'm doing", makes it impossible (for now) to rely on this in any type of a widely-deployed Enterprise setting. This just made the highly risky move of moving to Zig make it darn near impossible. Wha…

Unfortunately there's a lot of people on the internet who haven't even used Zig nor plan to use it anytime in the future and who just enjoy to create drama by amplifying any decision with a hint of controversy around it (also see the 'unused variables are errors' drama which turned out to be a non-issue after it was actually implemented). Unrelated to Zig, it's the exact same thing with "WASM can't access the DOM" bt…

The fact that WASM requires a JS is a marketing fail and misses what could have been a marketing opportunity to make the claim, "finally an alternative to JavaScript".

In this case, this is not a non-issue. If you look at the original github issue, it does a lot of damage, followed by a lot of confusion, followed by a damage-control post that shouldn't have been required if it the original issue was written with more care. It wasn't, because the marketing aspect of Zig was not the focus -- the technical issue was. So it blew up. Hopefully it'll be a lesson learned, but I suspect it isn't. It will take 20 more of such incidents before it sinks in.

As far as it was "announced years ago", I don't see how that matters. The people who are seeing the issue now, and this discussion weren't there to see the announcement years ago.

But I do understand what you're saying. You're point is that the onus is on the the reader to the do their research before overreacting. That's a perfectly fine position. I have a counter opinion which is that the person making the statement / claim / annoucement, simply be understanding of the implication of their statements.

This thing blowing up should not have been a surprise to anyone. Sounds like it would have been to you, so the fact that it blew up is evidence that you would have misjudged. Unless you also agree that the initial message should could have been better worded, in which case, what exactly are you disagreeing with?

Re: C Macro Reflection in Zig

#87

Post by throwawaymaths »

kbolino wrote: post #78
throwawaymaths wrote: post #51

Earlier quoted context omitted.

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

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

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.

Re: C Macro Reflection in Zig

#88

Post by throwawaymaths »

flohofwoe wrote: post #76
kasajian wrote: post #69

Earlier quoted context omitted.

Sounds like damage control. I have to say, for a brilliant guy, andrewrk knows nothing about marketing. The fact that the Zig project can make this significant of a change to their core-value because "trust me i know what I'm doing", makes it impossible (for now) to rely on this in any type of a widely-deployed Enterprise setting. This just made the highly risky move of moving to Zig make it darn near impossible. Wha…

Unfortunately there's a lot of people on the internet who haven't even used Zig nor plan to use it anytime in the future and who just enjoy to create drama by amplifying any decision with a hint of controversy around it (also see the 'unused variables are errors' drama which turned out to be a non-issue after it was actually implemented). Unrelated to Zig, it's the exact same thing with "WASM can't access the DOM" bt…

You have to admit that "divorce" was not really a good metaphor, though it did get eyes on the drama.

Re: C Macro Reflection in Zig

#89

Post by throwawaymaths »

jeltz wrote: post #82
flohofwoe wrote: post #76

Earlier quoted context omitted.

Unfortunately there's a lot of people on the internet who haven't even used Zig nor plan to use it anytime in the future and who just enjoy to create drama by amplifying any decision with a hint of controversy around it (also see the 'unused variables are errors' drama which turned out to be a non-issue after it was actually implemented). Unrelated to Zig, it's the exact same thing with "WASM can't access the DOM" bt…

The LLVM divorce has also gotten criticism since it first was announced and we have so far not seen any complete solution. Maybe we will land in one but if people did not voice their concerns there is no reason to think such a solution would be found.

What is there to criticize though? What "solution" is necessary?

LLVM is not and was never going away as a compiler backend, it will just not be the default one and you will be able to compile zig without it (though in practice everyone will for prod releases)

Re: C Macro Reflection in Zig

#90

Post by kbolino »

throwawaymaths wrote: post #87
kbolino wrote: post #78

Earlier quoted context omitted.

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

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.

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
Post reply on HN