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.
In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into threads about Zig to remark how immoral it is to use Zig, and now LLM shovel sellers are telling everybody that the only way forward is to become efficient at consuming tokens.
But it's actually not that bad.
The Zig community is growing pretty well, useful software is being written in Zig, and the advantages that Zig brings are still valid whether you hand-code or use LLMs (e.g. cross-compilation of C/C++ code).
The question is why would you fare any better if you don't use it. I don't know how it will play out, but this much I know: I will never pay for AI music, because I can replicate it for free. I'm still buying music from real musicians (in fact tons more than ever before), because I can't. Similarly, I have contributed to many FOSS projects (both financially and in PRs), but will not (knowingly) do the same for the ones that are vibecoded. Whether that will amount to anything or is just a fart in the wind, we'll see.
(Aside wrt being more effective with something than without: this is anecdotal, but my paragliding instructor once said that modern wings are often designed to correct for various pilot errors. He advised against buying those because he had seen people make worse mistakes after getting accustomed to them. In his own words: "you become dumber under a smart wing". Sharing because I think this applies to many things in life.)
[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC3639428/
[2] https://pmc.ncbi.nlm.nih.gov/articles/PMC2670101/
[3] https://www.sciencedirect.com/science/article/pii/S074756322...
[4] https://www.dailycal.org/news/campus/academics/failing-grade...
Vibecoding $x gives you pretty much the understanding of "someone else did $x," which seems unsurprising to me. There's a lot of usecases for code where "someone else did $x" is a perfectly fine way to accomplish $x! There are also many cases where "someone else did $x" is not a substitute for "I did $x."
"I want a tmux theme that fits with my existing zsh and neovim themes." Is it useful to me to learn how tmux themes work? Eh, marginally maybe? I'm personally kinda hoping I'm not using tmux in 10 years, so probably not.
"I'm writing code for work, where a bad correctness bug would be very expensive." If I'm pulling in someone else's code, I /better/ be auditing that code.
Like, this seems like the obvious framing and a useful heuristic? Maybe the problem is the subject of "vibecoded" is usually "I vibecoded this with Claude," not "Claude vibecoded this with me?" IDK
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)
I doubt this from my personal experience. Every week after a release, I see tweets complaining how AI wrote some depreciated code because Zig is making breaking changes every release. (They are valid in doing so, it's just not AI friendly yet)
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.
First of all, past trend doesn't predict the future.
And if it did, then the answer would be nothing will matter in 20 years. Not just "no programming language," but nothing.
Rust is a great language with some great killer features.
It does not need consistent propaganda preaching how it's a better choice than "insert other language".
Every system programmer is aware of Rust and it's pros. Doesn't mean it's a language that fits the use case, project, constraints and even preferences. It's not just about generating code, it's also about reading it and maintaining it.
Thus some people just prefer alternatives, be it C, C3, Odin, Zig, Jai or whatever else there is.
You said it yourself, it's selling point is "nicer C", so it's for people that don't want to write Rust or C++ but a nicer C.
Indeed. There is an irrational urge in some folks to become language-missionaries. Usually such folks have gained expertise in that specific language and want to protect and expand their turf. There is a wide-range of software usecases requiring a variety of tools and no one language fits all.
Amusing side-note. xai was all-in on rust for their ai-stack back in 2023. But now, spacex controlled xai is apparently coding ai in C - perhaps with the attitude that if a language is good enough to control rockets it is good for ai.
And specifically, why would Rust be a better choice than C or Zig when the LLMs get good enough to just write memory safe code in unsafe languages (they are already pretty good at finding memory safety bugs).
IMHO for code generation, different things start to matter (like fast build times, while 'convenient highlevel abstractions' become less important).
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.
Thanks for the link! Unfortunately, contrary to what the title suggests, that video seems to be more about AI than about the migration? (Sigh…) I did, however, find the following document where they explain why they migrated to Zig. It makes for a nice read: https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...
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.
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)
Do you think that this is a list of software that have never had memory bugs? It really is not practically possible to completely avoid a large class of memory bugs in C in just about any kind of very large commercial or open source codebase.
Redis
CVE-2025-49844 ("RediShell"): use-after-free in bundled Lua parser https://github.com/redis/redis/security/advisories/GHSA-4789...
CVE-2022-24834: heap overflow in Lua cjson/cmsgpack https://github.com/redis/redis/security/advisories/GHSA-p8x2...
CVE-2021-32761: OOB read / integer overflow in BIT commands https://security-tracker.debian.org/tracker/CVE-2021-32761
CVE-2023-41056: heap overflow on buffer resizing https://github.com/redis/redis/releases/tag/7.0.15
CVE-2021-32765: integer overflow to heap overflow in hiredis https://github.com/redis/redis/security/advisories/GHSA-833w...
Sqlite
CVE-2020-11656: use-after-free in ALTER TABLE https://bugzilla.redhat.com/show_bug.cgi?id=1824185
CVE-2022-35737: array-bounds overflow in printf engine https://blog.trailofbits.com/2022/10/25/sqlite-vulnerability...
CVE-2023-7104: heap overflow in session extension https://sqlite.org/forum/forumpost/5bcbf4571c
CVE-2020-9327: NULL pointer dereference in isAuxiliaryVtabOperator https://nvd.nist.gov/vuln/detail/CVE-2020-9327
CVE-2019-9936: heap over-read in FTS5 https://nvd.nist.gov/vuln/detail/CVE-2019-9936
OpenBSD
CVE-2023-25136: pre-auth double-free in OpenSSH sshd https://seclists.org/oss-sec/2023/q1/92
CVE-2022-27882: heap overflow in slaacd https://blog.quarkslab.com/heap-overflow-in-openbsds-slaacd-...
errata 70/003: kernel memory leak closing unix sockets https://www.openbsd.org/errata70.html
errata 74/018: buffer over-read in sndiod https://www.openbsd.org/errata74.html
errata 78/013: use-after-free in httpd chunked encoding https://www.openbsd.org/errata78.html
Git
CVE-2022-41903: OOB write in pretty.c format_and_pad_commit() https://github.com/git/git/security/advisories/GHSA-475x-2q3...
CVE-2022-23521: OOB write/read in .gitattributes parsing https://nvd.nist.gov/vuln/detail/cve-2022-23521
CVE-2022-39260: heap overflow in git shell split_cmdline() https://github.com/git/git/security/advisories/GHSA-rjr6-wcq...
CVE-2016-2315: heap overflow in path_name() https://bugs.launchpad.net/bugs/cve/2016-2315
CVE-2016-2324: integer overflow to heap overflow (nested trees) https://nvd.nist.gov/vuln/detail/CVE-2016-2324
So much so that I am at the moment doing the ziglings exercises and learning it over Rust (which I gave up on some time in the past, because it didn't spark "joy" for me; so far Zig does).
Sure, for now it is just a hobby programming lang to me, but it might become more than that.
You either care about non-functional aspects of your code, or you don't. Running your code through the shredder that destroys everything you don't test while insisting on writing it on a language that specifies non-functional properties... I don't have any other word, it's stupid.
Not all vibe coding is top down "Claude build X", it can be very specific implementation guidelines and criteria.
Whether Zig will become dominant in that space remains to be seen.
After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does.
Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done.
If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value". And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
I know this is probably not what the author meant. First of all "having a process" doesn't mean completing the process. Second of all, you can categorize bugs as being of a specific kind (The linked article under [fixing all bugs] actually only talks about failing asserts).
This doesn't make sense at all.
Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature is not a bug. It's just an item on a wishlist.
>If you have a bug to fix to weigh against a feature to add, which do you pick?
Depends on the seriousness of the bug. If your disk backup software corrupts backups, I'd fix that, I wouldn't go add schedulled backups or encryption first.
If what you meant to say is that bugs and features are both items to prioritize when deciding work, sure. But they're not the same thing and are not hard to tell apart, so the metaphor doesn't work.
Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.
It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks into thinking”.
Especially with dramatic processes like ”always fix all bugs before implementing any feature”.
You want to say that they're not the same kind of work? True. And yet, when you're allocating work, that doesn't particularly matter.
Well, they did claim something more though though: "the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features".
Well, no. Take TeX as an example. It does what it does. Bug are bugs, and they can fix them. Lack of features are not bugs. They can absolutely close to fixing all bugs. And some small programs can be 100% bug free (or close), without considering any rando's future request (which can expand to the thousands unrelated asks you never planned it do) as "a bug".
A bug means that there is a feature, but it's not behaving as was specified. (Or expected, or as it used to ... but clearly a difference to something, not to nothing)
It doesn't matter whether to the end user that's indistinguishable. It is for us, the professionals.
It's the same as with any other profession and domain-knowledge. If my heater doesn't work but it used to work, that's a bug, a regression. If it doesn't integrate with my smart home, that's not a bug. It was never a feature to begin with.
> If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value".
I agree.
> And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
Depends entirely on the project and the revenue stream. I've open sourced code which I consider done. It does what it should do and I won't any more features to it.
I will however fix bugs within the existing functionalities.
For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.
Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Now you implement the printing feature. There is an infinity of things to handle there. You add the 99.9% case which is basically regular printers, perhaps normal paper sizes. You however don't throw in things like document splitting (sending different pages to different devices based on capability). You have to stop somewhere. None of this is specified, however. None of the limitations are communicated to users. But you added the feature - in some sense. Then a customer with a 1970's pen plotter files a bug report that your new feature doesn't work on his device. Will you fix his bug? He's the only one on the planet with the problem. Is it a bug or a new feature? To him it's _clearly_ a bug. To you it would _clearly_ be a new feature to support pen plotting. You could argue the semantics of whether this is a bug or a feature until the sun goes down and it doesn't really matter. Either the fixed bug/added feature has enough value to be done, or it doesn't.
A key takeaway here: this isn't merely something that appears in the perspective of the user vs the developer. The argument about whether you actually have a "Bug" because you stopped short of implementing every kind of printing known to man is one you could have with your PM too. He likely didn't even consider that. But does that make it not a bug?
It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.
- trying to do X, getting software error: bug
- wishing the software did Y, even though it’s not implemented: bug
Especially when you implement it exactly as directed by a project manager. Everyone forgets why it was done the way it was done, and then the same project manager asks for it to be "fixed" despite it being the way they wanted it in your original ticket.
I have worked in companies where "X is not complete" would be logged as a bug. Even beyond that, non-completeness often leads to behaviors, especially as users bed in around non-complete interfaces, that are obviously bugs, crashes and the like.
If software represents a theory, any expansion in that theory (new features) will tend to lead to non-completeness, which will tend to lead to bugs. This is almost a mathematical certainty.
Engineering around this implies restating your theory, and thus performing partial or total rewrites of your software, quite regularly. It's not as crazy an idea as it sounds, I'm sure there are architectural patterns that make this manageable.
The answer to that is sadly "yes".
> prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.
That's why we pay senior developers lots of money. Their gut feeling (or past scars) about what actually gives value across different horizons.
-- C. A. R. Hoare
I've come to realize it's all about perspective. Something from the engineering stand point may not be a bug because there's nothing to fix. But the user might be having a bad experience because of that so it must be a bug.
In the end, the user's perspective might be the less-wrong one.
From a user perspective, a bug is when behavior deviates from reasonable expected behavior.
From a dev perspective, a bug is when the code actions mismatches the mental model (aka spec if it exists, else a reasonable mental model of the system).
A bug becomes a feature when it becomes expected behavior.
There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do.
This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.
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.
There is a lot to dislike about this paragraph:
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.
And no, asserts don't fix all bugs, they just guarantee some of your invariants are held at best, used in test at worst.
https://joshlf.com/posts/memory-safety-life-and-death/
Under a "it doesn't matter it's memory-safe if..."
In general, the article is ok-ish: it makes sense to think about the correctness (whatever that means... correct according to whom?), about the bugs (according to what specs?), the users (according to what use cases?). This is ill-defined and I don't like this framing. But even assuming I like the concept, why would the author say those things about rust specifically? This seems a bit like picking to me. Kind of not very honest, maybe?
I don't know or follow the author, just stumbled on this page because a colleague mentioned it, I don't know if there is a history of anti-rust'er or something, I just found something weird and sus.
> 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.
I posted this link at the same time when I posted it to Lobsters (https://lobste.rs/s/g6lkw1/my_software_north_star) 3 days ago, but it didn't get on the front page. Seeing that the submission time has been reset, I imagine it was given a second chance by HN curators (it's a known process), but that doesn't mean free upvotes, it's just that some people resonate with the thinking.
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.
EDIT: doesn't really answer your question. Just reminds me of a good ol' flamewar.
What makes you think that?
> I wonder why picking on Rust specifically.
I did not see that. What did I miss?
What kind of 'useful'? Normative? Empirical? Prescriptive? Pragmatic?
'Useful' is a very subjective north star.
Someone says it's useful to them. If you get a consensus where >50% find it useful, then it's probably useful.
By that same measure: correctness, maintainability, and efficiency are not that useful.
I wasn't saying usefulness is not important, I'm saying this post conveniently crammed the hardest problem of writing software into a fuzzy adjective.
In enterprise usefulness is not the end goal either. Software can be very useful, but if no one is going to pay for it, it holds very little value for the business.
for me, the end user's experience goes above all.
> I do not hear the end user, therefore it does not exist
Not literally, but that's what it feels like.
It's probably safer, but in the long run you're not building any trust.
The implication is that you should always strive to release software that isn’t overly buggy, isn’t slow, and is general a pleasure to use.