chaz72

The comment he is responding to expresses contempt for Zig’s LLM policy, and does so in a thread that is unrelated to Zig’s LLM policy. I think he’s showing some frustration here, but frankly I get it. Would anybody like to comment on the post?

I think all he’s saying is ‘feel free to use LLMs however you like, that isn’t related to how we use them on our project’. (I have no affiliation to Loris or the Zig project, just offering a suggested translation.)

No worries, I take your word for the status of these in Rust and I don’t need those features in my own Zig comptime code which as I said in a different comment, has been very predictable over the last few years. Thanks for explaining though!

> Ideally f(x) means the same thing whether evaluated by the compiler or by the generated program.

Absolutely, that’s why I wanted to know what types of things aren’t covered yet, and that’s also why I don’t share your certainty that they won’t be resolved later.

I hear you but I’m not sure it’s as dramatic as that, it’s also been quite predictable in my use over the last few years since I haven’t happened to use floating point or different endianness.

I get it now. Important things but not things that I use often - hopefully addressed by 1.0.

Now I see this response, I responded to the other comment.

And they believe Zig comptime wouldn’t do that? For the same inputs? I’d love an example.

Are you saying that you think that Zig does not produce identical outcomes for comptime code regardless of when the code runs? What do you mean?

Regardless of focusing on correctness or performance, it looks to me like the author didn’t understand arenas that well.

Like the other commenter said, “You use an arena when you have computation that might consume a bunch of scratch memory, and then you want to free all of that memory at once when the computation is done.” That’s the entire point of arenas.

My reasoning, which you may not agree with, is that I think that I have seen pron say unkind words before and I thought I had a better chance of persuading Steve to let it go. (Sorry pron, that’s how I was thinking of it. No, I have no specific examples.)

The fact is that every thread about Zig is filled with this kind of battle, and I’m tired of it, and it doesn’t represent any community, it’s so much worse on HN than anywhere else, and it’s all just defensiveness and crap.

I do see that you often have kind words for Zig and some attempt to more precisely define the differences.

What I mean is a bit different though, it’s that these arguments you get drawn into end up drowning out any real discussion of Zig’s progress. I don’t think that’s your intent but it is frustrating. I should be clear, I don’t think it’s wrong for you to defend yourself from accusations etc., I just wish it didn’t look like this.

I wonder how much better HN would be if they took a page from other forum systems that said “you know what, this whole branch of stuff should be moved over here and renamed so the original topic can move on”.

Sorry, all this may be unhelpful, I don’t know where the line should be, I’m just thinking out loud about the problem.

Yes! I think Fil is great so far but I think as he gets a bigger audience he should, well, consider that and focus on clarity a little more than humor. You can see Andrew’s growth in that respect.

Rust folks, this whole thing is a thread about Zig’s new feature - not even a memory safety-related feature! - and we cannot spend the whole damn time talking about Rust.

Steve, even you - I don’t believe I have ever seen you say an unkind word. But have you considered that it may be unkind to have written more than half of the words on a thread about a Zig performance feature?

If you choose to build static or dynamic libraries, I expect you’d still get to do that, and I expect as long as those don’t change and only the main binary needs patching it’d work the same. (Though I’m waiting for the next tagged release to really try it out myself, so that’s not like a guarantee or anything.)