Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig Libc

ziglang.org

Post reply on HN
Print view View original

151–160 of 196 posts

Re: Zig Libc

#151

Post by tristan957 »

sltkr wrote: post #109
tristan957 wrote: post #104

Earlier quoted context omitted.

Denouncing ICE is not denouncing federal immigration law. The Department of Homeland Security did not exist until 2003. Are you saying that prior to 2003, the US did not enforce federal immigration law?

What's your point? Immigration law existed before 2003 too. It might not have been the DHS or ICE enforcing it, but the concept of illegal aliens wasn't invented in 2003. And yes, I interpret “Abolish ICE” to mean “don't enforce federal immigration law”, because that's what people _usually_ mean when they say “abolish ICE”. Technically, “abolish ICE” could also mean: “abolish ICE and replace it with an even more ruth…

Andrew doesn't need to write anything. You're making a bad faith argument.

> I think it's reasonable to assume that he means to literally abolish Immigration and Customs Enforcement, leaving the US without Immigration and Customs Enforcement.

You really don't think that the US had federal immigration enforcement before 2003. Very strange.

Re: Zig Libc

#152

Post by jibal »

audunw wrote: post #139
WalterBright wrote: post #127

Earlier quoted context omitted.

D can import C files directly, and can do C-source to D-source translation. D can compile a project with a C and a D source file with: dmd foo.d bar.c ./foo

Do you have to bring up D in every Zig related post? I do like D. I've written a game in it and enjoyed it a lot. I would encourage others to check it out. But it's not a C replacement. BetterC feels like an afterthought. A nice bonus. Not a primary focus. E.g. the language is designed to use exceptions for error handling, so of course there's no feature for BetterC dedicated to error handling. Being a better C is th…

This is a bad comment in so many ways.

Walter's short limited comment was quite relevant.

Re: Zig Libc

#153

Post by Zambyte »

voidUpdate wrote: post #130

Does anyone know if there is a timeline on when Zig might achieve 1.0? I've been interested in the language for a while, but I'm a bit concerned about writing anything important in it when it seems to be evolving so much at the moment

Nobody knows, but for what it's worth, existing large projects that are used in production environments have been fairly good at keeping up with Zig releases. See: Bun, Ghostty, and Tigerbeetle for good examples of this. Because the semantics of Zig are relatively simple, porting to the latest version is usually as simple as bumping your compiler version, trying to build, making a fairly mindless, mechanical change, and repeating until it builds.

The biggest thing holding me back from using Zig for important projects is the willingness of my peers to adopt it, but I'm just building projects that I can build myself until they are convinced :)

Re: Zig Libc

#154

Post by ale »

rudedogg wrote: post #73
ale wrote: post #49

Earlier quoted context omitted.

i tested sonnet 4.5 just last week on a zig codebase and it has to be instructed the std.ArrayList syntax every time.

I made a Zig agent skill yesterday if interested: https://github.com/rudedogg/zig-skills/ Claude getting the ArrayList API wrong every time was a major reason why It’s AI generated but should help. I need to test and review it more (noticed it mentions async which isn’t in 0.15.x :| )

Fighting fire with fire

Re: Zig Libc

#155

Post by jibal »

voidUpdate wrote: post #130

Does anyone know if there is a timeline on when Zig might achieve 1.0? I've been interested in the language for a while, but I'm a bit concerned about writing anything important in it when it seems to be evolving so much at the moment

There's no timeline for 1.0

You might find this interesting: https://www.youtube.com/watch?v=x3hOiOcbgeA

Re: Zig Libc

#156

Post by DannyBee »

ibejoeb wrote: post #22
comex wrote: post #20

Earlier quoted context omitted.

It is viable against the IR that static libraries contain when LTO is enabled. LTO essentially means “load the entire compiler backend into the linker and do half of the compilation work at link time”. It’s a great big hack, but it does work.

Right, but I think that's what the question of "Why is the linker too late?" is getting at. With zig libc, the compiler can do it, so you don't need fat objects and all that. --- expanding: so, this means that you can do cross-boundary optimizations without LTO and with pre-built artifacts. I think.

Calling this "properly" is a stretch at best.

I will say first that C libc does this - the functions are inline defined in header files, but this is mainly a pre-LTO artifact.

Otherwise it has no particular advantage other than disk space, it's the equivalent of just catting all your source files together and compiling that. If you thikn it's better to do in the frontend, cool, you could make it so all the code gets seen by the frontend by fake compiling all the stuff, writing the original source to an object file special section, and then make the linker really call the frontend with all those special sections.

You can even do it without the linker if you want.

Now you have all the code in the frontend if that's what you want (I have no idea why you'd want this).

It has the disadvantage that it's the equivalent of this, without choice.

If you look far enough back, lots of C/C++ projects used to do this kind of thing when they needed performance in the days before LTO, or they just shoved the function definitions in header files, but stopped because it has a huge forced memory and compilation speed footprint.

Then we moved to precompiled headers to fix the latter, then LTO to fix the former and the latter.

Everything old is new again.

In the end, you are also much better off improving the ability to take lots of random object files with IR and make it optimize well than trying to ensure that all possible source code will be present to the frontend for a single compile. Lots of languages and compilers went down this path and it just doesn't work in practice for real users.

So doing stuff in the linker (and it's not really the linker, the linker is just calling the compiler with the code, whether that compiler is a library or a separate executable) is not a hack, it's the best compilation strategy you can realistically use, because the latter is essentially a dream land where nobody has third party libraries they link or subprojects that are libraries or multiple compilation processes and ....

Zig always seems to do this thing in blog posts and elsewhere where they add these remarks that often imply there is only one true way of doing it right and they are doing it. It often comes off as immature and honestly a turnoff from wanting to use it for real.

Re: Zig Libc

#157

Post by mg794613 »

bachmeier wrote: post #144
audunw wrote: post #139

Earlier quoted context omitted.

Do you have to bring up D in every Zig related post? I do like D. I've written a game in it and enjoyed it a lot. I would encourage others to check it out. But it's not a C replacement. BetterC feels like an afterthought. A nice bonus. Not a primary focus. E.g. the language is designed to use exceptions for error handling, so of course there's no feature for BetterC dedicated to error handling. Being a better C is th…

This is, like, the most ironic comment ever posted on HN. An article about cat nutrition could hit the front page and the Rust fanbois would hijack the conversation. In this case, however, Walter was not the one that brought up D. He was replying to a comment by someone promoting Zig with the claim that only Zig and C++ have ever had a strategy to replace C. That is objectively false. There's no way to look at what D…

No, he never stated that "claim that only Zig and C++ have ever had a strategy to replace C", you made that up. And "Walter was not the one that brought up D" , he actually was.

Did the text get changed? because it seems you claim exactly the opposite of what is in about ~5 sentences, so it also can't be credited to "misunderstanding".

But didn't find any "D evangelism" comments in his history (first page), but then again, he has 78801 karma points, so I am also not going to put energy in going through his online persona history.

Re: Zig Libc

#158

Post by bigstrat2003 »

boston_clone wrote: post #133
sltkr wrote: post #111

Earlier quoted context omitted.

Would you really make the same argument if those two words were “White power!” or something?

Hey it’s only the first week of February - isn’t it a bit early to be vying for most egregious example of a false equivalence?

No, the point is valid. The reason milch is saying "it's only two words what's your problem" isn't because it's only two words, it's because they are expressing a message he finds to be acceptable. The parent poster was attempting to point that out by showing there are "two words" messages he wouldn't support.

Re: Zig Libc

#159

Post by GoblinSlayer »

audunw wrote: post #139
WalterBright wrote: post #127

Earlier quoted context omitted.

D can import C files directly, and can do C-source to D-source translation. D can compile a project with a C and a D source file with: dmd foo.d bar.c ./foo

Do you have to bring up D in every Zig related post? I do like D. I've written a game in it and enjoyed it a lot. I would encourage others to check it out. But it's not a C replacement. BetterC feels like an afterthought. A nice bonus. Not a primary focus. E.g. the language is designed to use exceptions for error handling, so of course there's no feature for BetterC dedicated to error handling. Being a better C is th…

C++ is more C-like than Zig and Rust, so it's more likely to become a C replacement.

Re: Zig Libc

#160

Post by pjmlp »

DannyBee wrote: post #156
ibejoeb wrote: post #22

Earlier quoted context omitted.

Right, but I think that's what the question of "Why is the linker too late?" is getting at. With zig libc, the compiler can do it, so you don't need fat objects and all that. --- expanding: so, this means that you can do cross-boundary optimizations without LTO and with pre-built artifacts. I think.

Calling this "properly" is a stretch at best. I will say first that C libc does this - the functions are inline defined in header files, but this is mainly a pre-LTO artifact. Otherwise it has no particular advantage other than disk space, it's the equivalent of just catting all your source files together and compiling that. If you thikn it's better to do in the frontend, cool, you could make it so all the code gets…

Yeah, like their solutions to detecting use after free are hardly any different from using something like PurifyPlus.
Post reply on HN