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

121–130 of 139 posts

Re: C Macro Reflection in Zig

#121

Post by pjmlp »

3836293648 wrote: post #105
bluGill wrote: post #65

Earlier quoted context omitted.

C++ fears getting reflection wrong, which is why it takes a long time to get it in.

C++ fears getting lots of stuff wrong, which is why they got rid of good concepts, waited 20 years and then added bad concepts

So is the fate of design by committee languages and APIs, where not always the best comes out, rather what the people that decided to show up voted on, and those hard enough to keep battling for their papers throughout all voting sessions until the final victory.

Re: C Macro Reflection in Zig

#122

Post by flohofwoe »

classified wrote: post #120

Thank Apple for Reader View in Safari. If you are as incompetent in visual design as the author of that page, you should really stay away from dark mode. Your readers will thank you.

What's wrong with green-on-black? I'll take that over amber-on-black any day even if amber is apparently better for CRT burn-in.

Re: C Macro Reflection in Zig

#123

Post by pta2002 »

ajnin wrote: post #55
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

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

I think for better or for worse it makes sense that this is delegated to a separate package. For me it always seemed like a weird tangential thing that Zig did that is not really related to Zig The Language, and more to Zig The Build System. It made more sense when they were depending on LLVM either way, but now that they're closer to getting rid of it, it does not make sense to keep the dependency just for something that always seemed more like a 'neat thing' than a core language feature.

Re: C Macro Reflection in Zig

#124

Post by rk06 »

flohofwoe wrote: post #122
classified wrote: post #120

Thank Apple for Reader View in Safari. If you are as incompetent in visual design as the author of that page, you should really stay away from dark mode. Your readers will thank you.

What's wrong with green-on-black? I'll take that over amber-on-black any day even if amber is apparently better for CRT burn-in.

It is jarring when you use light mode. There is also issue with contrast. The red const gave me enough pain that I switched to reader view

Re: C Macro Reflection in Zig

#125

Post by mafuyu »

jay-barronville wrote: post #117
samatman wrote: post #115

Earlier quoted context omitted.

We have different ideas of what a big deal is, clearly. The idea that C programmers, C programmers , are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible. The complexity has moved to a slightly different place. That's it.

> The idea that C programmers, C programmers, are going to start bailing en masse out of the top of the Zig funnel, because they have to copy-paste a build.zig gist to get started? This is risible. What I find incredible about these takes is that they’re so removed from reality. It’s quite unfortunate how difficult it is to get a lot of programmers to evaluate things from the shoes of others. I have firsthand experie…

As an embedded C developer who has since branched out to Rust and C++, I’m definitely curious about Zig. Reading about this, I’m a bit split. Losing some of the C interop “magic” sucks, but the proposal to use the Zig build system seems pretty reasonable.

Really, I think what C developers want is a modern, opinionated tooling solution a la cargo. If the Zig build system can deliver that (plus the much better ergonomics of the language itself), I think it could be very compelling.

I’m sick of Make, CMake, Nix flakes, Docker, manually bundling specific arm cross toolchains, etc. If I can send someone a Zig + C project and the zig.build Just Works, I’m all for it.

Re: C Macro Reflection in Zig

#126

Post by ajnin »

flohofwoe wrote: post #62
ajnin wrote: post #55

Earlier quoted context omitted.

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

See: https://github.com/ziglang/zig/issues/16270#issuecomment-161... The ability to seamlessly compile C/C++/ObjC code within a Zig project is extremely important for me as well, but I'm fine with that job being delegated to a Zig package and the Zig build system.

I read that commment as well but if you need to use the Zig build system it means you won't be able to integrate Zig into an existing project as easily, you'll have to integrate the Zig build system or even to integrate your project into the Zig build system, and that's an another level of complexity entirely.

Re: C Macro Reflection in Zig

#127

Post by laeri »

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…

In this case you probably haven't looked at it properly. There is just the starting entry main.zig, and a root.zig file which you can remove if you don't need it. Nothing complicated or annyling problems at this stage.

Re: C Macro Reflection in Zig

#128

Post by chvrchbvrner »

jay-barronville wrote: post #91
throwawaymaths wrote: post #51

Earlier quoted context omitted.

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

> What's the problem? @cImport is becoming just @import. You’re oversimplifying what’s actually a significant change. Right now, I can do the following: 1. Download a prebuilt Zig release [0], on a fresh computer (zero prerequisites). 2. Implement a C library foo via foo.h and foo.c. 3. Compile foo.c into an object file foo.o via `zig cc`, using standard GNU-compatible compiler flags, for virtually any of the common…

> The build system requirement may seem minor if you’re already a Zig programmer, but it’s massive if you want to attract C systems programmers.

You won't need knowledge of the build system nor a 'build.zig'.

After step 4 you would run 'zig translate-c' on 'foo.h'. Then use '@import' instead of '@cImport' in step 5 for the translated file.

'@cImport' is basically just doing that under the hood. It's an additional step for the user, that's a fair point, but I definitely wouldn't call it massive.

Re: C Macro Reflection in Zig

#129

Post by classified »

flohofwoe wrote: post #122
classified wrote: post #120

Thank Apple for Reader View in Safari. If you are as incompetent in visual design as the author of that page, you should really stay away from dark mode. Your readers will thank you.

What's wrong with green-on-black? I'll take that over amber-on-black any day even if amber is apparently better for CRT burn-in.

If you have to ask that, please don't make dark-mode pages.

Re: C Macro Reflection in Zig

#130

Post by mst »

ajnin wrote: post #126
flohofwoe wrote: post #62

Earlier quoted context omitted.

See: https://github.com/ziglang/zig/issues/16270#issuecomment-161... The ability to seamlessly compile C/C++/ObjC code within a Zig project is extremely important for me as well, but I'm fine with that job being delegated to a Zig package and the Zig build system.

I read that commment as well but if you need to use the Zig build system it means you won't be able to integrate Zig into an existing project as easily, you'll have to integrate the Zig build system or even to integrate your project into the Zig build system, and that's an another level of complexity entirely.

There are enough people who care about adding zig to existing projects being easy (including the zig BDFL) that I would hope that this approach won't be stabilised until they're confident that it isn't adding enough extra complexity to spoil the experience.

I mean, we'll have to wait and see, and there may be a transition period during which things kinda suck, but zig has a pretty good track record here so I'm more optimistic than I would be in most cases.

Post reply on HN