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

101–110 of 139 posts

Re: C Macro Reflection in Zig

#101

Post by jay-barronville »

throwawaymaths wrote: post #96
jay-barronville wrote: post #92

Earlier quoted context omitted.

> 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. It 100% is a big deal. I explained this in another comment [0]. [0]: https://news.ycombinator.com/item?id=41111445

I think you are operating from a mistaken understanding, as responded to in the linked comment.

> I think you are operating from a mistaken understanding, as responded to in the linked comment.

No, I’m not. Respectfully, you’re responding to my point while admitting in your comment [0] that you don’t actually know.

If you read the relevant discussions, the conclusion, last time I checked, was that there’s going to be a build system requirement.

[0]: https://news.ycombinator.com/item?id=41111542

Re: C Macro Reflection in Zig

#102

Post by throwawaymaths »

jay-barronville wrote: post #101
throwawaymaths wrote: post #96

Earlier quoted context omitted.

I think you are operating from a mistaken understanding, as responded to in the linked comment.

> I think you are operating from a mistaken understanding, as responded to in the linked comment. No, I’m not. Respectfully, you’re responding to my point while admitting in your comment [0] that you don’t actually know. If you read the relevant discussions, the conclusion, last time I checked, was that there’s going to be a build system requirement. [0]: https://news.ycombinator.com/item?id=41111542

I "don't know" because zig 0.14 is not released yet and anything could happen but I DO know that imports do not currently require the build system. And I THINK that's because the core parts of the build system (including binding imports) are dependent on the command line anyways. So I am ASSUMING that property will be invariant when the c @import gets implemented, and my "don't know" is merely being explicit about that assumption. You are the one coming from a place of ignorance here, and your refusal to acknowledge that you might be wrong makes me suspect your argument is not being made in good faith.

Re: C Macro Reflection in Zig

#103

Post by jay-barronville »

throwawaymaths wrote: post #102
jay-barronville wrote: post #101

Earlier quoted context omitted.

> I think you are operating from a mistaken understanding, as responded to in the linked comment. No, I’m not. Respectfully, you’re responding to my point while admitting in your comment [0] that you don’t actually know. If you read the relevant discussions, the conclusion, last time I checked, was that there’s going to be a build system requirement. [0]: https://news.ycombinator.com/item?id=41111542

I "don't know" because zig 0.14 is not released yet and anything could happen but I DO know that imports do not currently require the build system. And I THINK that's because the core parts of the build system (including binding imports) are dependent on the command line anyways. So I am ASSUMING that property will be invariant when the c @import gets implemented, and my "don't know" is merely being explicit about th…

> You are the one coming from a place of ignorance here, and your refusal to acknowledge that you might be wrong makes me suspect your argument is not being made in good faith.

You’re making a lot of “assumptions” when you could just read the GitHub issue regarding this change, written by Andrew himself, titled “move @cImport to the build system” [0].

By the way, please note that I not only write Zig code almost daily, I’ve personally contributed to the Zig build system.

[0]: https://github.com/ziglang/zig/issues/20630

Re: C Macro Reflection in Zig

#104

Post by pharrington »

kasajian wrote: post #69
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...

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…

Zig's not at version 1.0.0 yet. Yes, it would be very irresponsible to use current-day Zig in a widely-deployed Enterprise setting. The release notes explicitly acknowledge Zig is currently immature, and is currently only suited to people willing to participate in the language development process.

Re: C Macro Reflection in Zig

#105

Post by 3836293648 »

bluGill wrote: post #65
Joker_vD wrote: post #63

Earlier quoted context omitted.

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.

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

Re: C Macro Reflection in Zig

#106

Post by dangets »

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…

This type of stance is what de-popularized the Elm language.

Don't get me wrong - I wish the best for both languages and am thoroughly impressed by the work of their creators. I can see that it must be a hard thing to balance.

Re: C Macro Reflection in Zig

#107

Post by uecker »

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…

In the unix world we use distribution package managers. This has many advantages, including security updates, some robustness against supply chain attacks, large-scale integration. All this language-level packaging systems are a mistake in my opinion.

Re: C Macro Reflection in Zig

#108

Post by nkozyra »

acedTrex wrote: post #61
ajnin wrote: post #54

Earlier quoted context omitted.

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.

I agree that letting the community completely dictate direction is a bad idea, but so too is being so dogmatic and idealist that you ignore the feedback.

Rust definitely swayed more to the former than I'd have liked, but you also have Go as a counterexample where generics were dismissed for a decade+ in response to user feedback and then kind of :shrug: ok fine we'll add generics.

Re: C Macro Reflection in Zig

#109

Post by TwentyPosts »

throwawaymaths wrote: post #96
jay-barronville wrote: post #92

Earlier quoted context omitted.

> 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. It 100% is a big deal. I explained this in another comment [0]. [0]: https://news.ycombinator.com/item?id=41111445

I think you are operating from a mistaken understanding, as responded to in the linked comment.

Andrew (in the linked Github page) answered a question as follows:

> Question: "So after this change, is there way I can still simply call zig run or do I have to use a build.zig file?"

Andrew's answer: "No, this use case will regress."

This in fact literally states that "just" calling "zig run" won't be possible anymore, and heavily implies you'll need a build.zig file.

Re: C Macro Reflection in Zig

#110

Post by WalterBright »

throwawaymaths wrote: post #99
WalterBright wrote: post #97

Earlier quoted context omitted.

Imports are found along the search path (just like .h files are searched for by the C preprocessor). The first one found it the one selected (just like the C preprocessor does). > Which import did that MessageBoxA come from? If it exists in two or more imports, the compiler will give an ambiguity error. To resolve the ambiguity error, qualify the call with the name of the import: windows.MessageBoxA(null, "world!", "…

Compiler giving a compiler error still favors the writer, not the reader of code. It seems like in its design in general D favors the writer of code with all its complicated bells and whistles that one must keep in mind as a reader. I think decades of experience has shown us that it is way better to favor the reader.

You can do it either way in D. It's nice to have a choice! I use both methods, depending on the context.
Post reply on HN