I imagine it's a difficult time to be a Zig developer.
In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code - why open yourself up to memory unsafety on top of everything else? Further, the Zig community appears to value a hand-crafted, 'artisanal' approach to software development, which is the very antithesis of vibecoding.
I have no particular interest in Zig as a language but definitely feel some empathy here. The industry is changing in ways that many of us are struggling to process.
Agreed unfortunately, if Zigs whole selling point is meant to be a "nicer C" (and a much nicer DX than Rust because no fighting the borrow checker etc) - does that really matter in a world where an LLM is writing the code? I am not going to be fighting the borrow checker, the LLM is.
And as always, the response you'll hear is: but AI sucks/hallucinates/could never replace me etc... Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years. I don't see how Zig makes sense if this is the trajectory the industry is going.
the zig team says that in the future stabilizing the IR and providing an API will happen.
fwiw in the process of building this project the llms have never once written a memory safety error in the "lib" section (in the src section there was a lot of tripping over segfaults since memory mapping datatypes accessed by a dylib can get hairy)
> In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
Meanwhile, some projects are doing the opposite, like going from Rust to Zig, here's an example from a podcast I recently listened to: https://www.youtube.com/watch?v=XSXGf3oN2yU
I think Bun just got a lot of visibility because of the speed and scope of the migration, which both shook things up and I guess was good PR cause that made a lot of headlines.
I wish Roclang well but (as a regular listener to Feldman's podcast) I don't think we can draw many conclusions from this switch other than "Feldman has lots of opinions on lots of things".
1. Fixing memory errors wasn't the reason the project migrated to Zig, but a beef between the Bun maintainer not getting his own changes in the upstream compiler and the Bun's new employer focus on Rust.
2. You can write memory safe code in C (Redis, SQLite, OpenBSD, Git, etc), let alone in Zig which provides more tools to write memory safe code.
3. AI can write very good Zig already. This isn't 2024 anymore where "the LLM has seen lots of this language so will write better in this language" scenario existed. Will make you an example: I have worked in a very esoteric typescript fork called TS plus (providing among others fluent style apis for pipe-able functions) and even Opus 4.1 did well. Recently I have forked the Elm language and the LLM had no problem dealing with it, despite significant differences to the original Elm.
4. Zig's community uses Zig because it likes Zig and its tooling and doesn't like the constraints of other languages. Simple as that.
Damn this person's obviously is so bitter towards Rust... I wonder why he's so obsessed with it?
I mean, if they really care about software correctness, I wonder why take a very discutibile position and say that "safety doesn't matter if you don't use the correct process". Yeah, I mean, having some guardrails is better than none, right? If they really cared about correctness, they would really strive to put all the possible guardrails in place, wouldn't they? Maybe they are bitter because their fav language is not as popular as the other?
But there are so many languages, I wonder why picking on Rust specifically.
I don't get it. Are we reading the same article? This article is so generic that it reads like vacuous truth to me. But I don't see their bitterness towards Rust (or anything, really. It's just vacuous.) from it. Is this person a famous anti-rust'er or something?
It's like saying it doesn't matter if surgery is done another antiseptic conditions if the patient isn't also given a course of antibiotics during recovery.
It's not an argument against safe practices, it's an argument for amending one kind of safety with others.
What 'all the comments'? There aren't many comments in this thread. You mean this: https://news.ycombinator.com/item?id=48432736 ? I flagged it too. I think the flag is quite justified.
oh I don't particularly care I'm just asking what is it about this article that is so worthy of being front page? I'm literally just calling out the content. I'm sorry for complaining.
It’s getting attention because the subtext of the article is the zig vs AI ideological battle going on (and zig vs Rust somewhat on the backburner)
Recent events AFAIU:
- bun (bought by big AI) switching to Rust
- zig team banning AI pull requests (because they want to review humans)
- The cloud industry buying all coding tooling companies (uv, vite, bun) but zig being unbuyable
If anybody from the zig core team is reading this: thank you and carry on the good work.
so im just getting caught up with zig is I have never really paid attention to it
so far I'm not really getting zig and I see they banned AI ? seems like that is just going to attract anti-AI user base...not sure if that was a wise decision.
also not really sure why anyone would migrate from Rust to Zig, it seems much less mature and unsure of the ROI there.
It's bland and generic because it's a manifesto. Author (and HN submitter) is Loris Cro, aka @kristoff_it, VP of Community at Zig Software Foundation.
In his role, devising as set of general guidelines to use as compass when things (inevitably! and often!) get very very muddy and Right v. Wrong is hard to tell apart -- both objectively, and also from the point of view of being a community leader with ton of vested interest -- is essentially one half of his job. Other half is abide to said guidelines.
So @kristoff_it last week sat down, came up with three simple rules short enough he can print on a business card (or hang on his office wall or whatever), and posted them here to test if they make sense to the wider community.
TLDR: yes can seem bland / generic but within context it makes sense to me author needed to distill his ethics in a nutshell.
> It doesn’t matter that the language you use is memory-safe
> nobody can trick me into mistaking lesser stars for my true destination
The author seems to be in some level of denial around compile-time safety checks. They're right that runtime safety errors are an issue, but it feels wrong to discount compile time checkers when it can save a lot of yak shaving.
>It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
It's also worth noting that they linked a post about how memory safety is literally a matter of life and death, so it seems like their point is that memory safety is one class of bug, and a compiler guarantee about it doesn't equate to a guarantee of correct, bugless, unexploitable code.
Like, the linked author brought up that Khashoggi's wife's phone was hacked. Maybe that was due to a memory bug or some other kind of bug. Maybe the next journalist who gets hacked is a victim of a memory bug or some other kind of bug. But that linked post didn't take a holistic view of correctness, but went straight to, "Rust is safe. Rust saves lives." There's a logical error there that's being pointed out.
If you really want to save lives, you need to eliminate exploits. Not just do a victory lap because your compiler ostensibly eliminates one class of them. The compiler doesn't catch all bugs. The compiler isn't the only tool for catching bugs.
That's my reading of it, anyway. I think he has a point, and the Rust people do as well. I think it's wrong to portray him as bitter.
That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post is doing, won't make you create better software.
If Rust helps you get all the way to correctness, then great, but that blog post was insane.
I imagine it's a difficult time to be a Zig developer.
In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code - why open yourself up to memory unsafety on top of everything else? Further, the Zig community appears to value a hand-crafted, 'artisanal' approach to software development, which is the very antithesis of vibecoding.
I have no particular interest in Zig as a language but definitely feel some empathy here. The industry is changing in ways that many of us are struggling to process.
Agreed unfortunately, if Zigs whole selling point is meant to be a "nicer C" (and a much nicer DX than Rust because no fighting the borrow checker etc) - does that really matter in a world where an LLM is writing the code? I am not going to be fighting the borrow checker, the LLM is.
And as always, the response you'll hear is: but AI sucks/hallucinates/could never replace me etc... Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years. I don't see how Zig makes sense if this is the trajectory the industry is going.
> before Zig gets properly established.
zig is reasonably established. the llms write pretty good zig. see project linked below which is almost entirely llm-written
> And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code
why? because one project that was shipping fast made a dog's breakfast of it?
> why open yourself up to memory unsafety on top of everything else?
this can be addressed by third parties in the reasonable near-term. for example:
https://github.com/ityonemo/clr
the zig team says that in the future stabilizing the IR and providing an API will happen.
fwiw in the process of building this project the llms have never once written a memory safety error in the "lib" section (in the src section there was a lot of tripping over segfaults since memory mapping datatypes accessed by a dylib can get hairy)
> In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage.
Meanwhile, some projects are doing the opposite, like going from Rust to Zig, here's an example from a podcast I recently listened to: https://www.youtube.com/watch?v=XSXGf3oN2yU
Here's the project in question: https://github.com/roc-lang/roc
I think Bun just got a lot of visibility because of the speed and scope of the migration, which both shook things up and I guess was good PR cause that made a lot of headlines.
I wish Roclang well but (as a regular listener to Feldman's podcast) I don't think we can draw many conclusions from this switch other than "Feldman has lots of opinions on lots of things".
1. Fixing memory errors wasn't the reason the project migrated to Zig, but a beef between the Bun maintainer not getting his own changes in the upstream compiler and the Bun's new employer focus on Rust.
2. You can write memory safe code in C (Redis, SQLite, OpenBSD, Git, etc), let alone in Zig which provides more tools to write memory safe code.
3. AI can write very good Zig already. This isn't 2024 anymore where "the LLM has seen lots of this language so will write better in this language" scenario existed. Will make you an example: I have worked in a very esoteric typescript fork called TS plus (providing among others fluent style apis for pipe-able functions) and even Opus 4.1 did well. Recently I have forked the Elm language and the LLM had no problem dealing with it, despite significant differences to the original Elm.
4. Zig's community uses Zig because it likes Zig and its tooling and doesn't like the constraints of other languages. Simple as that.
Believe what you want, I guess.
https://xcancel.com/jarredsumner/status/2055796104302858694#...
> I’m just tired of dealing with crashes and memory leaks & want language features to help prevent things
(Edit: this reply seemed less flippant before the parent edited their reply)
The adjective 'useful' is doing a lot of the heavy-lifting here.
What kind of 'useful'? Normative? Empirical? Prescriptive? Pragmatic?
'Useful' is a very subjective north star.
Damn this person's obviously is so bitter towards Rust... I wonder why he's so obsessed with it?
I mean, if they really care about software correctness, I wonder why take a very discutibile position and say that "safety doesn't matter if you don't use the correct process". Yeah, I mean, having some guardrails is better than none, right? If they really cared about correctness, they would really strive to put all the possible guardrails in place, wouldn't they? Maybe they are bitter because their fav language is not as popular as the other?
But there are so many languages, I wonder why picking on Rust specifically.
I don't get it. Are we reading the same article? This article is so generic that it reads like vacuous truth to me. But I don't see their bitterness towards Rust (or anything, really. It's just vacuous.) from it. Is this person a famous anti-rust'er or something?
But it links to this post
https://joshlf.com/posts/memory-safety-life-and-death/
Under a "it doesn't matter it's memory-safe if..."
You may be misinterpreting the intended meaning.
It's like saying it doesn't matter if surgery is done another antiseptic conditions if the patient isn't also given a course of antibiotics during recovery.
It's not an argument against safe practices, it's an argument for amending one kind of safety with others.
It's so bland and generic its bizarre like somebody is botting it. Weird that all the comments calling this out are getting flagged or downvoted.
What 'all the comments'? There aren't many comments in this thread. You mean this: https://news.ycombinator.com/item?id=48432736 ? I flagged it too. I think the flag is quite justified.
oh I don't particularly care I'm just asking what is it about this article that is so worthy of being front page? I'm literally just calling out the content. I'm sorry for complaining.
It’s getting attention because the subtext of the article is the zig vs AI ideological battle going on (and zig vs Rust somewhat on the backburner)
Recent events AFAIU: - bun (bought by big AI) switching to Rust - zig team banning AI pull requests (because they want to review humans) - The cloud industry buying all coding tooling companies (uv, vite, bun) but zig being unbuyable
If anybody from the zig core team is reading this: thank you and carry on the good work.
so im just getting caught up with zig is I have never really paid attention to it
so far I'm not really getting zig and I see they banned AI ? seems like that is just going to attract anti-AI user base...not sure if that was a wise decision.
also not really sure why anyone would migrate from Rust to Zig, it seems much less mature and unsure of the ROI there.
It's bland and generic because it's a manifesto. Author (and HN submitter) is Loris Cro, aka @kristoff_it, VP of Community at Zig Software Foundation.
In his role, devising as set of general guidelines to use as compass when things (inevitably! and often!) get very very muddy and Right v. Wrong is hard to tell apart -- both objectively, and also from the point of view of being a community leader with ton of vested interest -- is essentially one half of his job. Other half is abide to said guidelines.
So @kristoff_it last week sat down, came up with three simple rules short enough he can print on a business card (or hang on his office wall or whatever), and posted them here to test if they make sense to the wider community.
TLDR: yes can seem bland / generic but within context it makes sense to me author needed to distill his ethics in a nutshell.
oh. I've never heard of zig. I use Rust.
> It doesn’t matter that the language you use is memory-safe
> nobody can trick me into mistaking lesser stars for my true destination
The author seems to be in some level of denial around compile-time safety checks. They're right that runtime safety errors are an issue, but it feels wrong to discount compile time checkers when it can save a lot of yak shaving.
Quote the entire sentence.
>It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
It's also worth noting that they linked a post about how memory safety is literally a matter of life and death, so it seems like their point is that memory safety is one class of bug, and a compiler guarantee about it doesn't equate to a guarantee of correct, bugless, unexploitable code.
Like, the linked author brought up that Khashoggi's wife's phone was hacked. Maybe that was due to a memory bug or some other kind of bug. Maybe the next journalist who gets hacked is a victim of a memory bug or some other kind of bug. But that linked post didn't take a holistic view of correctness, but went straight to, "Rust is safe. Rust saves lives." There's a logical error there that's being pointed out.
If you really want to save lives, you need to eliminate exploits. Not just do a victory lap because your compiler ostensibly eliminates one class of them. The compiler doesn't catch all bugs. The compiler isn't the only tool for catching bugs.
That's my reading of it, anyway. I think he has a point, and the Rust people do as well. I think it's wrong to portray him as bitter.
That is correct, this blog post is about understanding the priority of various subgoals and the ultimate goal (creating useful software). Memory-safety is important but overfitting on that subgoal, as I believe the memory-safety blog post is doing, won't make you create better software.
If Rust helps you get all the way to correctness, then great, but that blog post was insane.
the piece didn't really seem very targeted at Rust as much as it's targeted at projects claiming to be secure just because they're written in Rust
from his about page: "I'm VP of Community at the Zig Software Foundation"
EDIT: doesn't really answer your question. Just reminds me of a good ol' flamewar.
> Damn this person's obviously is so bitter towards Rust
What makes you think that?
> I wonder why picking on Rust specifically.
I did not see that. What did I miss?