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

61–70 of 139 posts

Re: C Macro Reflection in Zig

#61

Post by acedTrex »

ajnin wrote: post #54
Laremere wrote: post #27

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…

Wow, that actually makes me want to look into zig a lot more. so many projects, rust included, get bogged down in design by committee and half baked decisions that please no one.

Re: C Macro Reflection in Zig

#62

Post by flohofwoe »

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.

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.

Re: C Macro Reflection in Zig

#63

Post by Joker_vD »

bluGill wrote: post #47
JonChesterfield wrote: post #10

Earlier quoted context omitted.

Clang prints out things about macro instantiations on the semantic error reporting paths. That probably means it has all the macro information available already. It's not probably reflected to the language because C++ fears reflection in general and hates macros in particular.

Reflection is on track for C++26 so it is completely wrong to say C++ fears reflection.

Reflection proposals have been around at least since 2014, so I'd say it's exactly right to say that C++ fears it — otherwise it'd have arrived much sooner.

Re: C Macro Reflection in Zig

#64

Post by Joker_vD »

bluGill wrote: post #46
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…

> 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). Package managers are a lot more complex than people realize. Every attempt I've seen in every language has significant lacks for common real world cases. Most commonly they assume all the world…

Why would anyone want to integrate with the OS package manager? Windows, as you've said yourself, doesn't even have one (and thank goodness for that) while on Linux, the distributed packages are normally about 2 to 4 years out of date — unless you discover and use specific 3rd-party repositories at which point what's even the point then? Just use the language's CPAN/PyPI/Hex/Crates.io/etc. analogue.

Re: C Macro Reflection in Zig

#65

Post by bluGill »

Joker_vD wrote: post #63
bluGill wrote: post #47

Earlier quoted context omitted.

Reflection is on track for C++26 so it is completely wrong to say C++ fears reflection.

Reflection proposals have been around at least since 2014, so I'd say it's exactly right to say that C++ fears it — otherwise it'd have arrived much sooner.

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

Re: C Macro Reflection in Zig

#66

Post by bluGill »

greenavocado wrote: post #50
bluGill wrote: post #46

Earlier quoted context omitted.

> 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). Package managers are a lot more complex than people realize. Every attempt I've seen in every language has significant lacks for common real world cases. Most commonly they assume all the world…

Weird take. Does pip have to interface with the Windows or iOS package managers? No. Yet it's wildly successful.

> Does pip have to interface with the Windows or iOS package managers? No. Yet it's wildly successful.

Successful I agree. I have issues on any system I use it on because now I have the package installed by PIP and the package installed by my OS package manager - slightly different.

Re: C Macro Reflection in Zig

#67

Post by bluGill »

Joker_vD wrote: post #64
bluGill wrote: post #46

Earlier quoted context omitted.

> 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). Package managers are a lot more complex than people realize. Every attempt I've seen in every language has significant lacks for common real world cases. Most commonly they assume all the world…

Why would anyone want to integrate with the OS package manager? Windows, as you've said yourself, doesn't even have one (and thank goodness for that) while on Linux, the distributed packages are normally about 2 to 4 years out of date — unless you discover and use specific 3rd-party repositories at which point what's even the point then? Just use the language's CPAN/PyPI/Hex/Crates.io/etc. analogue.

> Why would anyone want to integrate with the OS package manage

Because if they don't integrate you end up with several different versions of the same package installed. When you program grabs the wrong version how do you fix it. Now what if you are in support trying to help a customer.

> on Linux, the distributed packages are normally about 2 to 4 years out of date

Maybe you need to find a different distribution. Some make it a point to be out of date. Some make it a point to be up to date.

Re: C Macro Reflection in Zig

#68

Post by jordanozang »

greenavocado wrote: post #50
bluGill wrote: post #46

Earlier quoted context omitted.

> 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). Package managers are a lot more complex than people realize. Every attempt I've seen in every language has significant lacks for common real world cases. Most commonly they assume all the world…

Weird take. Does pip have to interface with the Windows or iOS package managers? No. Yet it's wildly successful.

If you use pip without protection, it will gladly and malevolently mess up your system. Every Python user learns quickly about the virtual environment work around. Various distributions (e.g. through Homebrew on Os X, Arch Linux, Ubuntu Linux) ship pip without the ability to make system-wide installations (externally-managed-environment). Even on Windows, where there is no standardized package management system, doing a pip install will place a bunch of dlls in the system's PATH that could get in the way of any program on your system.

The anti-solution of ignoring the problem is what got us here.

Re: C Macro Reflection in Zig

#69

Post by kasajian »

Laremere wrote: post #27
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…

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

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.

What he should have done is announce a project at the same time that will maintain the current developer experience, even if that project is not part of the zig foundation. The developer doesn't care about how he builds zig. They want 1) download 2) use. It doesn't matter from where. If today it's directly from zig, and tomorrow it's from elsewhere to download a combined package, that 's all the devs needed to hear.

Re: C Macro Reflection in Zig

#70

Post by deagle50 »

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 seems the build system has gotten enough traction and Andrew is going for broke to enshrine its place in the C space. I wouldn't bet against him.
Post reply on HN