Sunk cost fallacy can be a feature: if you have spent a lot of blood, sweat, and tears on a project, you are more likely to push it through adversity and the doldrums that inevitably one will encounter. If all it took was one of those momentarily brilliant ideas and a prompt on Claude to produce something, there is no attachment whatsoever to it.
Speaking as the ‘average programmer’, I have dozens of brilliant ideas per day that don’t stand the test of time or scrutiny, and the very few that pass the filter don’t seem that interesting days later, or worth the effort at all.
Ideas have always been cheap. Now, proof of concepts have become as cheap. I don’t care about your Show HN unless you have spent a month on it.
I sometimes think of something Kant wrote, about how friction (hardship, etc.) elevates us.
In Kant's own words:
"Without those in themselves unamiable characteristics of unsociability from whence opposition springs-characteristics each man must find in his own selfish pretensions-all talents would remain hidden, unborn in an Arcadian shepherd’s life, with all its concord, contentment, and mutual affection. Men, good-natured as the sheep they herd, would hardly reach a higher worth than their beasts; they would not fill the empty place in creation by achieving their end, which is rational nature. Thanks be to Nature, then, for the incompatibility, for heartless competitive vanity, for the insatiable desire to possess and to rule! Without them, all the excellent natural capacities of humanity would forever sleep, undeveloped. Man wishes concord; but Nature knows better what is good for the race; she wills discord. He wishes to live comfortably and pleasantly; Nature wills that he should be plunged from sloth and passive contentment into labor and trouble, in order that he may find means of extricating himself from them. The natural urges to this, the sources of unsociableness and mutual opposition from which so many evils arise, drive men to new exertions of their forces and thus to the manifold development of their capacities. They thereby perhaps show the ordering of a wise Creator and not the hand of an evil spirit, who bungled in his great work or spoiled it out of envy."
See the section titled "FOURTH THESIS" at the following link if interested.
https://en.wikisource.org/wiki/Idea_for_a_Universal_History_...
http://www.catb.org/~esr/writings/taoup/html/end-user.html
"""Master Foo turned to the end-user. “Tell me”, he inquired, “why do you seek the Way?”
“I am discontent with the software I see around me”, the end user replied. “It neither performs reliably nor pleases the eye and hand. Having heard that the Unix way, though difficult, is superior, I seek to cast aside all snares and delusions”."""
In game design friction very important; remove all friction and you don't even have a game any more, you might as well show the You Win screen. My favourite metaphor for it is sex: there is no sex without friction.
What LLM have done is massively reduce the friction of intellectual effort, completely devaluing most expressions of it.
Both needs heat.
This is all friction that is intended to make car-driving work at scale.
There really, truly, absolutely, 100% is no accounting for taste...
Worst of all I've seen good engineers lean in and begin thinking uncritically and magically.
1. Same services provided using similar software stack, but maintained by fewer developers. I suspect this may hold for some sectors in the economy. Or
2. The Jevons case: similar # of developers maintaining a much bigger software stack that provides more services.
I might add:
2a: Similar but with lots of accidental complexity everywhere.
Probably we're heading towards some mix of the above? Depending on which application area you're talking about. Web dev is a lost cause, deeply-embedded won't see a big shake-up.
"If one teenager works hard and saves for a few years to buy themselves a car and another has theirs bought for them on a whim, who would appreciate their car more?"
Odds are it's the former, not always. But mostly.
Let's first settle on the definition of vibecoding so that we're not miscommunicating over definitions. I'm using the one that seems the median definition nowadays: >95% of the code written by LLMs, <60% of the output code human-reviewed, meaning there's a large part of the codebase that no human ever reviews.
As you said it's about time invested in thinking about it, yes. But remember that even pre-AI >90% of software got never used, it was dead on arrival. Look up "success rate of software projects in business".
You can put lots of time into thinking and vibecode everything. You can put very little time into thinking and write by hand. Of course, vibecoding makes the former much more likely. But nothing about it is inherent to it.
The friction itself does not add value. The time spent thinking on the problem does. Friction should be minimized beyond the absolute bare minimum. Programming is a discipline where your workstation is already streamlined, and it is easy to forget where the friction is. Programming is done in a world of pure though, in a sense, so most of the friction already lives in your head, and it is difficult to distinguish effort wasted fighting friction from effort making real progress.
Consider the Wright brothers. They worked iteratively. When they wanted to design an airplane they moved from Ohio to a windy place with lots of loose sand (NC outer banks). Why? So that they could do test runs with good wind conditions (for an airplane that is barely able to fly this matters a lot) and crash with the least amount of damage. They rebuilt the airplane dozens and dozens of times and had a workshop tuned to their needs on location. They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
It seems that way, but that's not actually true. A fully greased-up brain would produce just incoherent nonsense decoupled from reality, because it would lack all constraints that would allow it to judge the value of an idea (i.e. how possible and useful it would be to implement in the real world). The friction comes from fitting your ideas into the real world.
>They reduced friction wherever they could so that they got the most work done that they could with the least amount of distraction.
They reduced unnecessary friction. They could have eliminated all friction by imagining a teleporter machine that can send you anywhere instantly and that runs on the hopes of children. But they still wanted the friction of unsuccessful attempts so they could actually build a plane that worked.
I would say that, within the Wright Brothers example, working with a battered, worn-out screwdriver is an example of friction (or, perhaps having to use a bit and brace instead of a power drill), but the act of building a new unsuccessful airplane iteration is not friction. Every build is asking physics for feedback on the design; every airplane build is just the same as running your code through the compiler. I wish I had a good word to distinguish this from friction. The closest thing I can imagine is how waste is defined in Lean Manufacturing, but keeping in mind that what you are manufacturing is Ideas and Software.
Concretely, If your only goal is to produce "software" then learning about design, planning, project management, testing etc is all unnecessary friction when you can just ask an LLM to "make it so"
You'll get the exact same muscle loss with a CICO calculation weight loss.
Exactly. I don't have to write binary machine code directly, every zero and one artisanally crafted by hand, to have thought deeply for years about a how to solve a problem.
In fact, choosing the right level of abstraction is essential to my ability to solve the problem.
For most problems, the friction of writing binary code by hand is the wrong level.
And we're discovering that many important problems can be solved faster and with greater quality than can be achieved by dogmatically hand-writing every line of source code just for the friction.
But overall yes, time spent thinking is the thing that matters.
It's less "there should be more friction" and more "LLMs remove too much". Instant gratification is great if you're a consumer, awful if you're a creator.
Thinking of software from finance and derivatives pov really blew my mind. here’s the article, it has AI smell but it’s short and the mental model is good: https://newsletter.kentbeck.com/p/the-cost-yagni-was-never-a...
it’s a breakthrough for me because i too like to build so it’s hard to not build. With options, i don’t get to build blindly but there’s still satisfaction in holding the option. collect the options, system design them, build on that layer.
To me the issue is that everything becomes written in the same style pattern. I don't know why but if I spot it I wince internally and immediately skim the post or just outright stop reading. A large part of it is overexposure. For me it's made browsing the internet quite uncomfortable since it's unavoidable.
I mainly spend my online time in group chats these days.
That is such a miserably low bar
(I’m pretty sure both you and I would “know it when we see it”, but…)
EDIT: this is the one I was thinking of...
https://sinclairtarget.com/blog/2026/06/01/quality-in-the-ag...
But this is relevant too...
https://bersas.substack.com/p/zen-and-the-dance-of-generativ...
That's not it at all.
The problem with AI slop is that in general it's not worth reading, because to start off even the author deemed the topic wasn't even worth writing to begin with.
Worst, most AI slop blog spam was obviously not even reviewed by the bloggers who prompted them into existence. This means is also content that even the bloggers themselves felt wasn't worth reading at all.
But somehow they expect us to invest our time reading AI slop?
> would spend more time writing than I would have to spend reading
To your point however, the reason people don't like AI generated blogs is because there is a explicit recognition that the author of the blog lacked effort. There is a visceral response for the reader about the social contract "if you didn't spend as much time as I did why should I care about what's written here", it's however NOT that the quality is inherently poor (but perhaps one my insinuate that notion).
Quality is a bit nuanced but that quality of AI generated content is subpar to expert output is fairly established.
The implications of this ever becoming false amounts to GAI.
Can you point us to a single blog (or even blog post) that is generated by AI that is excellent quality? Or even average quality?
Watch me.
I absolutely can and do. And pictures, and videos, and picture posts, and comics, and all image-format content.
If it wasn't worth creating with someone's brain, it is never ever worth my time to consume the prompt output.
Send me the prompt. I might look, if I'm bored.
I can and I will say that, if not only for the fact that, in the eyes of many people, AI and the botched launch of the past few years has incurred a great amount of distrust. But, going further, the vast majority of AI-generated blog posts are lower quality, because they lack human thought and effort behind them. I'm not saying AI is completely incapable of writing what a human can, but we can't relate to how it "thinks", if you can call it that, and if someone is going to put enough effort into curating an AI's output and coaching it to make it output something that is really of a high quality... they just put in all of the human effort it would have taken for them to write it themselves.
I also don't think this should be construed to mean that human-written posts are universally good. AI slop is just the latest and most farmable iteration of a long history of badly written and poorly thought out content on the internet. In some ways the average AI blog is probably more coherent than any flat earth blog.
I also think that that visceral disgust at consuming AI generated work points to something else. We are all still trying to grapple with the ethical boundaries of what is okay and what isn't okay to do with AI, but I think most people feel deceived when they find out they're watching an AI video, or reading an AI blog post, and rather than assuming people are wrong to feel that way, we should consider that their feelings on the matter do matter. Nobody wants to be fed algorithmically optimized fake slop by YouTube, and that's okay.
I think it's more than that. These greenfield projects are actually things that, up until the inception of LLMs, they were not worth creating.
With AI code assistants, the cost of developing them is lower, but in the end you still end up with a project that no one bothered to create.
But this is the longer running discourse about AI code's cost / benefit. I keep nagging my work's AI community to show me the numbers, so far nobody has been able to show an increase in productivity, quality, customer satisfaction, or company profits.
The only gain is speed.
I hate ai so much because its so easy to generate quick slop that "appears" functional.
Yes. I'm as pro-AI coding as people come, but this is the part that bugs me too. If you whip something useful up in a weekend, great!
But you don't have to present it like you are building an actual product. It's fine if no one else knows about it. Because the fact is, most people don't care, even before AI. Building for yourself is fine.
I dunno, this idea guy seems to have some really great ideas, what's wrong with you skeptical programmers who aren't on board implementing his ideas for equity?
100%, you actually stated it correctly. It's not "I don't care unless you've written/reviewed everything by hand". If someone writes something by hand in an hour, including ideation, and puts it on Show HN, realistically it's almost certainly not going to be worth even looking at.
I've been running an app in prod for more than a year now, mostly vibecoded long before HN believed it was possible - HN only started believing this around Jan this year at the earliest. But nobody who uses it cares, or even notices, because it took a month to build. That's what matters, the amount of time and thought put into it. Of course it's true that vibecoded projects have a much lower median amount of time and thought put into it. But that's like Louisiana having a much lower median income than California, it's just a median, not an inherent characteristic of being a Louisianan vs a Californian, there are plenty of poorer Californians and richer Louisianans.
The process of iteration, or the feedback loop, typically allows space to try things out and experiment and then either drop an idea or refine it more purposefully. And those breaks in between the pure delivery to focus on that gives you room to breathe and also see the progress of your work.
Blatting it out in 6 hours with Fable 5 skips all of that and you have something like an MVP, but you haven't really put anything of yourself into it. So why bother committing unless you can take that further or apply something novel or reflect your own personality in it? Or you genuinely believe you're on to something and the AI approach actually gave you a path to building it?
I've been 'vibe coding' something, I've spent about a month on it on and off along with a fair bit of debugging on some sticky issues. I still think I'd suffer going into that codebase and doing stuff in it by hand, no matter how well I thought I organised it all.
Obviously they have to start somewhere if they want to get to safe rust with a considerable degree of battle testing. So they decided to start with just a transliteration and go from there.
I think the Zig people are really just concerned that maybe Zig itself is a DOA language because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
Just search "segfault" on the Zig issue tracker and you'll see why people are starting to be skeptical of the future utility of such a language in the face of something like Rust.
Zig has 110 open "segfault" issues [1] versus Rust's 175 open "segfault" issues [2]. So, by your logic, Rust is also bad.
edit: I was just trying to point out that the parent's "just search segfault" argument is lazy. Also, Zig is still in beta.
[1] https://codeberg.org/ziglang/zig/issues?state=open&type=all&...
[2] https://github.com/rust-lang/rust/issues?q=is%3Aissue%20stat...
It's not even wrong.
That would be Zig's 700 or so Codeberg issues + the 2,700 or so GitHub issues.
On the other hand, as a corporate backer for Zig, TigerBeetle is definitely a big deal.
But in terms of exemplary and imitable projects in the ecosystem I would think something like Ghostty is the safer label for "flagship".
In fact we could summarize TigerBeetle as "the financial database developed like embedded software". Determinism is a cornerstone of critical software like in avionics, and naturally, dynamic allocation is forbidden, as in TigerStyle.
So even though it is not obvious, TigerBeetle represents one of Zig biggest strengths: embedded systems.
Their success with this strategy isn’t portable to most other projects. I think they really need more traditional flagship projects that generalize to typical memory management use cases. The way the conversation keeps coming back to TigerBeetle as a success story isn’t helpful to anyone trying to evaluate the memory management angle.
> only works for very specific use cases.
It's not clear to me what you mean by this.
I used "most" in the pedantic sense of "just a little bit over 50% if you count individual lines and not whole libraries". Most code doesn't operate on Box, Vec, String etc. directly, and is happy with & and &mut to underlying data. And even when it does, it's usually used for giving static lifetime to data, which is a non-issue here because all your preallocated memory has static lifetime already.
TigerBeetle calculates all the memory it needs at startup. It allocates that much memory once. It does not allocate memory dynamically.
This only works for very specific use cases, like a fixed server size where you know exactly how much memory you want to allocate to a process.
It’s not portable to general purpose computing, where it’s expected that apps aren’t allocating the maximum amount of memory they might use at startup. Their memory usage grows and shrinks as you open and close files or as your documents get longer.
> and the approach more commonly used in Rust (allocate wherever and whenever) is non-idiomatic in Zig
Allocating memory as needed isn’t a Rust-specific idiom. Most programming involves dynamic memory allocation.
I don’t think the Zig developers would go as far as saying Zig isn’t a good fit for dynamic memory allocation. If it was that simple this entire debacle could have been written off as “Bun requires dynamic memory allocation by nature, therefore Zig isn’t a good fit”. That’s not what Andrew Kelley is trying to say though.
So, like, the JVM with its "initial heap size" setting? After reserving that space from the OS on startup, pieces of the space are then handed out by the JVM's internal allocator, where and when needed.
If initial heap size and max heap size are the same, that initial one is the only malloc() call that ever happens. Not as common for desktop software, but a common best practice when deploying JVM applications to servers.
(I think we're perhaps tripping over two different meanings of "allocate" - you can "allocate" in the sense of calling malloc(), and you can "allocate" a piece of that reserved memory to a particular scope/function/object without actually calling malloc.)
> Allocating memory as needed isn’t a Rust-specific idiom.
I never said that.
You might be mixing it with the reference implementation for the standard, OpenJDK, and even then, it depends pretty much on which set of configuration parameters are given.
Does the program handle character data? It is indeed a rare server app which never handles strings.
On the other end, Rust to me felt like "better C++" - outside the embedded niche, aimed at complex multithreaded code that has to combine high performance with not catching on fire because someone fucked up concurrency once again.
But the main issue I had with Rust - that it's frankly a bitch to write, nearing Go levels of awful, only worthwhile if its paradigm is buying you a lot - is diminished if it's an LLM that's doing the bulk of the line to line writing.
And, on the other end, C's warts, footguns and ancient quirks also matter less if you have an LLM plow through it.
So, the niche for Zig does seem to be shrinking. The window for it to establish itself might be genuinely closing now. Which is a shame, because I like the idea of having "better C" a lot. But all of this drama sure isn't helping it gain traction.
Pre-2022, Zig was doing decently, but not particularly well. It didn't have Rust level of enthusiasts and ambassadors (love them or hate them, they did succeed in driving considerable Rust adoption), it didn't have a major corpo backing it, it had too much API instability to be truly relied on. Picking a stupid fight with Bun/Anthropic and doubling down on it isn't helping with any of that.
I also don't think compilation time makes for a good moat for agentic AI coding? Like, sure, less time wasted = better. But LLMs don't perceive time as humans do. They don't have the human "40 minutes of compile time = a hard forced context switch" quirk. The state of an LLM agent is as "stale" after a 40 minute build as it is after a 40 second build - no attention penalty for getting distracted.
There is a hard "wall clock time" iteration speed penalty, but I expect LLM coding to be more agentic, not less. In which case a single sub-agent stalling might not matter much? The orchestrator AI would just keep doing other things, and come back to the stalled sub-agent when it's ready. Once again: long stalls hurt the worst if they route through human attention. The less human attention there is in the system the cheaper they are.
1 minute skim of that surfaces aviaviavi's comment on moving to Python not Rust:
Main factors were (roughly in order):
- None of us are experts in Rust, and we're all solid at Python.
- Rust felt like an under-correction for what we wanted (get all friction in front of the LLM out of the way).
- Our high-performance stuff is not being migrated at this time (Scarf Gateway), so we're just talking about basic CRUD backends here. Basically any language will workI don’t think this is a huge moat any more. Structuring Rust codebases in a modular way to keep incremental compile times down is common. The biggest complaint about it is from people who simply don’t like the structure and want to put everything into one big package, but that’s a stylistic choice.
I used to think that there's a a room for better C -> Some unrelated complains about Rust and Go -> C has footguns, but they don't matter that much because I choose to not write my code myself anymore -> Therefore there's no room for better C.
'plow through it's?? An LLM can definitedly fall into these traps!
Happened to me a few months ago, I couldn't believe that an LLM would generate a use-after-free in not-so-complex code but it did.. Newer LLM seems better now but buyer beware!
Warts and ancient quirks, I can kind of see, but in what way have LLMs solved the footguns?
By now, if we're pitting a top of the line coding LLM against a B-tier programmer throwing something together in a hurry, I would expect the latter to shot more foot, and not by a narrow margin. Even those who know better don't always do better - for a human, "fucks given" is a painfully finite resource.
Go, awful? That's wild. I find Go to be maybe the most pleasant language I've ever used. It's just delightful for its niche (web services, system tools, things of that nature), I've never seen anything better.
That’s what I’m saying. I hear “Better C” and my initial reaction is “what’s the point”. Like, why would you aim for “Worse C++”?
I mean, compile times. That’s fair.
Granted we "aren't modules" yet, unless being on latest compilers with msbuild/cmake/ninja tooling.
But to your larger point I would much rather work on improving that than let it drive me back to C fetishism.
You hit the nail on the head there. Zig is 10 years old now and it’s pretty clear that the industry isn’t biting, compared to the behemoth that is Rust. Between Rust, C, and C++ there is very little room for another language with a woefully incomplete library ecosystem to establish itself.
A true competitor would need to offer genuine extra value, such as dependent types or other formal verification features, to carve out a niche.
Zig isn't finished yet (they still have not released a v1.0). They're still iterating on the language itself and want the flexibility to make backwards-incompatible changes while they do so.
So in a sense, they have not yet asked anybody in mainstream industry to "bite." After v1.0, when there's an understanding of stability and ongoing language support, industry adoption or lack thereof might become a relevant metric for measuring the project's health. But right now that's not relevant at all.
Either users think (a) it's actually ready after a decade, since many langs/libs are conservative with jumping to v1.0, or (b) they'll think it's [a toy/a side project/run by perfectionists] that's not ready for production, and might never be.
This isn't exactly fair for those who want to just take tir
He then told me that it is, as you said, unfinished, and that he can't reasonably recommend it for embedded projects that are often long term and demand stability. C, a 1970 language is still king for a reason! So he is keeping Zig on his watchlist for when it becomes more mature.
You are the typical mark for hype cycles. Get a clue will you.
Nope. I was on a Python project in 2006 and earned a paycheck doing so.
In the industry, how often is it that a tool/language is picked up for the ease of developing that tool, vs ease of using that tool?
believe it or not it is generally easy to do this with zig with few modifications (WIP), and the team has said publically that they will be making this sort of thing a supported operation once the IR stabilizes post-1.0.
Zig is kind of trapped. It can't go "head to head" with heavy weights like Rust, who specialize in safety, are more mature (post 1.0), and have lots of corporate support. Then there are the other C alternatives, who each offer something it doesn't have.
It appears the only way for it to maintain its position, is through heavy hype and marketing, but the whole Bun ordeal and extensive beta issues are subtracting from any such attempts.
[1]: https://c3-lang.org/
[2]: https://github.com/zenc-lang/zenc
[3]: https://learnxinyminutes.com/odin
I see Rust encroaching in proposed transitions. It may even happen. That said, it is a poor match for it compared to something like Zig (or Odin). It's hard to make the new Rust code use existing allocator abstractions (so now you have two systems doling out memory, how do you reliably free composite objects with memory from both? How do they share?) and you increasingly have to either abandon any actual benefits of the borrow-checker, or invest increasingly heavily into sufficiently fat bindings to wrap your existing C/C++ in a way where the borrow-checker can assist you. That's before we consider the complexity of the language - I'd doubt a seasoned C programmer has much trouble deciphering Zig or Odin FFI bindings, but in the case of Rust? Yes, there is real friction.
Also if you really value predictable- and higher performance, being in more in control of memory allocations and cleanup is preferable. This is the direction both Zig and Odin cater to.
If you asked me what solves the most issues without adding too many new liabilities, I'd say Zig (or Odin). It would simply be much, much easier to transition a C codebase to either, and either would bring a much improved stdlib with pluggable allocators capable of leak-detection etc.
Now, mixing different allocators is a different beast, and much less supported. But it sounds like you are very much not interested in this use case, right?
Just my opinion. It really depends. For systems- kind of software (low-level, DBs, file systems (also user-space)) no, I wouldn’t - if you manage memory with arenas and/or can plug in an allocator to tell you if you leaked memory (provided the codepath is triggered), I mostly get what I want with less mental overhead. Also, I very often want to interface with C libraries.
For games, again, I wouldn’t. I again strongly suspect I would and could organize my use of memory better.
I suspect Rust is best when you don’t want to interface with C code (except through bindings others wrote) and you’re maybe more doing applications development where C++ has also stood strong. I completely see how, theoretically, Rust can make a great language for an office suite, browser and so on.
That’s actually also when I tried Rust for a personal project. I wrote a desktop application and while I spoke to C code, I only did so through bindings others had written.
It was/is fine :) I still got a segfault bug though hehe.
Basically I liked Ocaml so I have huge appreciation for all that Rust tries to bring into the mainstream on that front. I am just not thinking that the borrow-checker makes it well placed to interop with C. It becomes much better for relatively isolated applications work.
The big problem is that many projects keep ignoring those tools, the way Zig sorts out reporting use after free errors, the same solution exists for C and C++ for about 30 years now.
Huge problem with this is that typically safe, idiomatic Rust looks nothing like unsafe Rust.
I don't think anyone who actually uses zig thinks "it doesn't offer enough over C". Removing #define alone would have been worth it.
If you reach out to any project manager and pitch the idea to rewrite a whole app from scratch because you want to get rid of #define, first you will be laught out of the room and second they will reach out to HR to get a PIP going because whatever the hiring bar they used to hire a developer you clearly are not meeting it.
I promise you, hand on heart, that literally no one on the Zig core team is wasting their time on thoughts like this.
> and their flagship project has now abandoned it.
Quoting Andrew:
> So, when the Anthropic aquisition finally happened, we at ZSF breathed a sigh of relief. When the donation silently stopped, our bank account was ready for it. When they neither canceled their monthly meeting with us, nor showed up, we were not surprised. The relationship was over.
I advise you to take this paragraph at face value. Again, I promise you that it is the truth.
In contrast with the Zig codebase, you now have clear well-scoped unsafe boundaries you can iteratively fix one by one. This was not the case before.
This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)
C is unsafe 100% of the time. Rust is only unsafe in unsafe{} blocks.
EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.
And how does Miri help solve this issue?
By the engineer's wit of course!
> And how does Miri help solve this issue?
By detecting undefined behavior caused by violation these rules
Seeing how the Rust compiler isn't an LLM, it can't really work on wit.
From the POV of a programmer, how would you implement an unsafe block? What is disabled vs what's enabled?
> By detecting undefined behavior
Say you are tasked with making Miri; how do you detect violations of these rules?
> We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.
What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic.
Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.
Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it.
Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.
So if I use Zig, I need to do all of that perfectly from day one and I don't get any help from static analysis to do it. Or else I've poisoned my whole program in scary ways and will require a total refactor where I still won't have any help and once again can't make a single mistake.
> [what you just wrote]
So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.
Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
We often ensure a project holds water against miri. This one doesn't even pass for clippy.
The difference is that in Rust you get strong guarantees for everything that is not inside of unsafe and clearly demarcated areas where things might go wrong. Even if you never eliminate a single unsafe block, the clear demarcation is valuable as an artifact in its own right.
Which is why having unsafe code without exactly specified invariants is practically useless: the Bun rewrite code has too many SAFETY comments that are incorrect and misleading, so most of the unsafe demarcations aren't helpful in achieving UB-free code.
First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient.
> What's your point, that if we can't do everything perfectly in one step we can't do it at all?
My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.
As in, they did not, which I can prove by using Miri and seeing hundreds of errors.
That's usually the case for Rust programs because the language encourages it. Are Zig programs like that?
and the rust version has been live in claude code since june 17th.
(I think wrapping a large, complex C/C++ codebase is where Rust often shines, if you build the right joiner abstractions. PyO3 is a really great example of that.)
It's also outside the scope of the project if they're using Webkit's engine for that part. Which means Bun itself isn't a JIT, it's all the stuff built around the Webkit JIT, so whether or not Rust is useful for the JIT is entirely immaterial to the question of if Bun would benefit from Rust.
> heap-use-after-free crash in node:zlib when calling .reset() on a zlib, Brotli, or Zstd stream while an async .write() is still in progress on the threadpool
https://github.com/spaceraccoon/vulnerability-spoiler-alert/...
If you look at the fix you can see its all in their zig codebase:
https://github.com/oven-sh/bun/commit/621c4016218bb782e05907...
What is kind of funny is that nodejs also had a basically identical bug with an almost identical fix:
https://github.com/spaceraccoon/vulnerability-spoiler-alert/... https://github.com/nodejs/node/commit/53bcd114b10021c4a883b0...
But now the interesting question, how does the code look like in Rust?
https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76...
It has the same guard in place as the zig and c++ versions, the rust code also just calls into the zlib bindings after the "write in progress" check.
So in this case at least the same exact use-after-free would've happened and they don't win anything from the rust port.
Another one was this:
> crash and out-of-bounds read in Buffer#copy and Buffer#fill when a valueOf callback detaches or resizes the underlying ArrayBuffer during argument coercion
I think ths is the fix:
https://github.com/oven-sh/bun/commit/79522ab6c579736dc239fa...
But the bug here is in C++ bindings, Rust wouldn't have helped here either.
Last one:
> double-free crash in the CSS parser when background-clip had vendor prefixes and multi-layer backgrounds
Fix: https://github.com/oven-sh/bun/commit/912970c98437e418a95b6b...
Code side-by-side:
Rust: https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76...
Zig: https://github.com/oven-sh/bun/blob/912970c98437e418a95b6b5b...
I can't judge the Zig code, perhaps someone could say if this was a "beginner" mistake.
But this is at least one case where Rust would've helped, although even that is a bit complicated considering stuff like bun_ptr:
// Lifetime-erasure helpers (RUST_PATTERNS.md §6/§18) — re-exported here so
// crates that already depend on `bun_collections` (logger, css, js_parser,
// crash_handler, watcher, http_types) can route the borrowck-dodge through
// one centralised `unsafe fn` instead of open-coding the lifetime cast.
pub use bun_ptr::{RawSlice, detach_lifetime, detach_ref};
The idea that "anything other then pure safe Rust is useless" is common (even among some Rust proponents, but generally not the most experienced ones), but it's a pretty fundamental misconception of what Rust actually offers. Safety is a spectrum, not a binary, and while the extreme end of "everything is guaranteed to be safe no matter what" is nice when you can get it, Rust is literally designed to solve the problem of giving you the ability to slide along the spectrum to calibrate to the most amount of safety you an achieve rather than being all-or-nothing.
If you still think there's no value in enforcing safety outside of the lowest level stuff like JIT, I'd suggest being more explicit about why you're confident that memory safety bugs wouldn't be a concern outside of those contexts. I've yet to hear an argument for why I shouldn't be concerned about memory unsafety in even relatively mundane code in memory unsafe languages that doesn't basically boil down to "just be really really careful", which I'd argue has been empircally shown to not work even a little bit no matter how skilled the programmers writing the code are.
Another definition: Rust is a lang to "Run fast and low-level software/firmware, with nicer tools, features, and syntax than the other langs which can do this"!
Obviously, the value proposition you find in this case depends on the subjective nature of that regarding rust vs zig!
"safety" is not why I use and love it. I brought this up because someone who hasn't used Rust, but reads about it may assume it's a "safe" language; I would describe it instead as a nice all-around language.
Rel: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
In hindsight having automated auto complete rewriting your code base wasn't something on 2000's radar.
Now switching from language to language is much easier. Just for Rust, there was Ladybird and Bun complete rewrite, that ran into zero things that Joel rallied about.
Joel argues 2 effects:
# Developer & time-cost of a rewrite is a big unknown. That's still true, but LLMs may cut that down by a factor of 10x or more. You cut time & developer-hours by throwing tokens ($) at it. An optimist might say this cost has vanished.
# Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
A single bug that pops up in the rewritten codebase (which wasn't in the old one) can hurt a vendor's reputation badly if the stars align just right.
All in all Joel's article held up pretty well (esp. given how long ago it was written).
I wouldn't say it vanished. I'd say it moved from unknown to known. It's highly likely that for code the size of Bun the price is around 200k dollars of tokens + a month of programmers time to monitor it.
> Shipping a rewritten product is -by itself- an unknown risk. That still holds. You can do all the testing you want, but your test suite != your clients environment(s? multiply by number of users or target platforms).
Fair point.
That said, it seems the number of relevant platforms is shrinking. Both on the hardware side - x86_64 AMD, x86_64 Intel, and aarch64. On the OS side, you have Linux, Mac and the dying Windows.
Still, it seems with enough tests and original source code, you can limit this risk to a few edge cases.
> All in all Joel's article held up pretty well
Aside from the fact that it mostly applies to commercial endeavors[1], it still missed the mark on old code decaying over time.
Turns out being exposed to the Internet has a chance to turn even old code sour.
[1] If you don't care about your users, or you care more about pleasing/attracting new developers, then points made in his article don't make rewriting it that bad.
Making software projects successful has always been about a lot more than just writing code. People have been "rewriting code from scratch" successfully even before LLMs. We just don't tend to call it that. We call it "cloning", "competition", "copy", "alternative-to", "reverse-engineering", "x-written-in-language-y", etc.
People did this also before LLM, but the difference is that now the prototype is a fully functional product in the technical sense whereas before it was little more than a glorified Hello World. The human effort and calendar time used remains roughly the same.
There's gonna be amazing products made with LLM, but it'll take some time. Not as long as it did before, but still significant time.
You think more amazing than what was made without LLM?
Example: Qobuz has no official Linux client, but there's https://qbz.lol/ which it seems to me is mostly vibecoded. It's not perfect, but it works pretty well and can do some fancy stuff like bit perfect DAC passthrough up to 192kHz/24bit.
But I'm asking something slightly different. I'm asking about something that's amazing, not due to a different economic calculus, but something that's AMAZING that would not be possible to create by humans.
They’ve just found a way to explore that logical fallacy even faster.
The existence of _two_ books, published by the same publisher, within a few years of each other, is a kind of tacit acknowledgement, that there are two categories of people (Owners/Founders and Developers/Coders), that have a kind of symbiotic relationship with each other. That relationship has always been a relationship of convenience and gain, not resonance and understanding and appreciation.
It is, in a way, similar to globalization: nations will support it, only to the extent that it can make them (or their elites) wealthier, and not because they actually care about peace, or the magnificent diversity of human culture and creativity.
Just as the globalized economy is fraying, so is the symbiotic relationship between Founders and Coders. I think it started with the pandemic, which caused (without pointing any fingers) a tension between Founders and Coders, and has been accelerated by LLMs. In some sense, the tactics that were use by Tech companies to wow and win customers outside of Tech, are now being used by Tech companies on other Tech companies. And those tactics involve making grand promises to people who have knowledge-gaps, and are otherwise easily impressed.
I did not realize that there even was a symbiotic relationship, until I analyzed US degree-completion-rates for 1970 to 2011[1][2]. I suppose it should have been obvious, but these things are difficult to perceive from the inside (even if you've been working in the industry for an entire decade). The big problem is that the symbiosis is asymmetrical: founders get the money, and pay the coders, and are able to fire and replace coders at will, while coders can do none of this to the founders. This may have been fine, in an era where layoffs were rare, and getting a replacement job was less uncertain. But I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders. Note that the Viaweb story (the archetypal startup-story for HN), is a story of Coders out-founding Founders (the equivalent of the late 90s era, did not found companies so much as administer small parts of them).
[0]: This is not a criticism of the author/interviewer, nor the interviewees -- the subject matter simply did not intersect enough with my own obsessions and fixations. I wish it did. It feels like I have some kind of color blindness, when it comes to "founder-y" things.
[1]: You can find a (fair warning: long) PDF here: https://galacticbeyond.com/pdf/two-percent-programmer.pdf
[2]: If you do not want to read all of that, here is a TLDR. The percentage of informatics-degree-completions never drops below 2% (which confirms an informal observation Knuth has made many times -- see his 3 or 4 oral histories and his interview in Coders at Work). The percentage of informatics-degree-completions rises and falls with business-degree-completions (the symbiosis is visible here). It never exceeds 4.5%, and such doublings coincide with bubbles (the dot-com bubble, and the 1980s AI-bubble -- there is a history section that helps narrate these numbers). Most intriguingly, informatics-degree-completions are _perfectly inversely correlated_ with healthcare-degree-completions -- their first-derivatives are nearly perfect mirror images. Also, the majority of graduates are business-graduates (accounting, administration, etc -- economics belongs to social-sciences instead of business), and their numbers have doubled since 1970, at the expense of social sciences and education (I suspect that this has had an impact on our (both global and American) culture akin to the impact that climate-change has had on our planet, but I have no data to put behind that suspicion, yet).
> I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders.
I think a lot of people will, but those who do probably weren't the target audience for Zig in the first place?
I still remember the Twitter dev blog where they abandoned Ruby/Rails and the damage that did. It turned out Twitter was doing a lot of stupid things and there was a mismatch of tools and their goals. They loudly blamed the tools and people ate it up because Twitter was big, visible and adored at the time. Their conclusions bypassed most people’s ability to reason.
Anthropic/Bun are big, visible and adored…
I saw a lot of RoR companies/users thinking “should we do the same?” without even realizing that they do not have the same twitter scalability problems.
The same engineer at Twitter decided early on that no distributed messaging technology was good enough for Twitter, so they wrote their own. It fell over and they threw it away and wrote their own again. It fell over and they threw it away and now they use mainstream tools.
Rust might be the right choice for Discord, I've no idea about that, but the problem is that the blog post lives on and influences people to this day.
It's not better, it's worse given the average bear's assumption about a rust project.
You are acting like they need to complete everything at once...why?
Bun (rust) is not even released as stable yet and getting extensive usage on Claude code. They are making improvements and fixes. So what's the issue here?
Claude Code was a vibe coded experiment, a "what if", that basically consumed software engineering in six months flat. Not because it's durable (it's not), but because the value it provided was so overwhelming.
People will use bad software if the value it provides is high. People will avoid the most durable and battle-tested software ever written if it doesn't actually provide value (solve a problem for them).
Creating software with AI is super easy--plan, prompt, test, go, go, go!
Owning software means you're responsible for maintaining it over time, fixing edge cases, operating it well, and more.
If you're building a one-off custom webapp to meet your needs, create away. If you're writing software for a business to run on, you're owning it. My fav article on this topic is this post[1] on durable vs disposable software.
0: https://www.linkedin.com/feed/update/urn:li:activity:7482123...
1: https://www.honeycomb.io/blog/disposable-code-is-here-to-sta...
I've gone back to Node.
There was a poll on r/bun with about 2000 votes and only about 30% of users voting they were going to use the Rust version. Can't seem to find it now.
Edit:
The poll was deleted
https://www.reddit.com/r/bun/comments/1u3j4d7/are_you_going_...
It is in the marketing. Most software engineers are not skilled at marketing, do not have a large audience, and are not willing to spend money on advertising. It has nothing to do with code quality.
Unsafe in theory in a transliteration is only as unsafe as the original Zig was, which makes it a perfectly reasonable place to land as a transition point in a way that introducing large numbers of allocations simply isn't.
Because most projects are abandoned within months. Why should they be any different in that respect?
I'm gonna offer an alternate theory. Because AI-generated projects are so cheap, there's no need to amortize them by advertising and creating a community. It works for you, you don't change your workflow, so there's no need to expand it. In this model, most AI-generated projects are done within days, not abandoned.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
I'm not convinced this explanation is self-evident enough to assert without any justification. I can think of at least one other plausible one, which is that maybe most side projects in general get abandoned after a certain amount of time, and being able to write the code a lot faster means that the point of diminishing returns for personal utility, enrichment, or pleasure are reached a lot faster.
https://www.ibm.com/products/open-enterprise-sdk-go-zos
https://www.ibm.com/products/open-sdk-for-rust-aix
This is the kind of industry support Zig is still years away to get, and in the AI age, most likely will never happen.
I wonder if new version of Bun has the same emotional values in Jarred's mind, I mean he did write it by hand and struggled for a long time and invested a lot of energy.
Meanwhile the rust rewrite just magically appeared to replace it.
Which one is more valuable for a person? High Effort or low effort?
It's worse, and I say this as an avid Rust fan and programmer. Try Miri with the new Bun project. It's currently blowing up. The Rust compiler's non-unsafe aliasing rules still need to hold during unsafe, which are far more complex than writing correct Zig code. That's the trade-off about Rust: The compiler has a ton of clever proofs for safe code, but if you're on your own, you'll have to do the work yourself.
The post starts off so cynical. I know a few people at anthropic and oai and the simplest explanation also matches my observations that they actually believe what they say. That agents will be doing the bulk of the programming in the not so distant future. They believe they themselves will be out of jobs at that point.
They aren't managing some message and trying to teach the anti AI folks a lesson.
Frequently, those alternative hypotheses are demonstrated to be true. For example, "emergence" as was researched and proclaimed by many labs, including places like OpenAI and Anthropic is due to using too few discrete steps in sampling a continuous phenomenon. See "Are Emergent Abilities of Large Language Models a Mirage?" [1] for example.
In the paper I linked, they talk of a particular take on the word that is commonly discussed in the ML research: between one discrete step and the next a phenomenon came into existence without existing before (i.e. it occurred spontaneously). The paper then goes on to refute specific claims. That's all I'm pointing out (I could point out similar issues with research into reasoning).
I think it's difficult to pin down "emergence" in the general sense as it likely goes into a deep philosophical argument like consciousness, so I'm unwilling to state whether or not some notion of "emergence" actually takes place. In that sense I agree with you.
now THAT is cynical
> They aren't managing some message and trying to teach the anti AI folks a lesson.
Unless you know the senior execs in charge of marketing at these companies I don't know how you can make that assertion. I believe that a lot of the folks at these companies earnestly believe in the work they are doing. But a belief held by software engineers is not automatically shared by the marketing department, nor by senior execs.
"Anthropic is a giant company with a lot at stake and will seek to capitalize on any marketing opportunity" doesn't strike me as cynical so much as a statement of fact.
Maintenance of the zig code was abandoned, while the port continued in the same repo, and it's unlikely any work on the zig branch will keep momentum. So yes it forked, but more in the fork+exec sense (or maybe just exec, the analogy's not that great).
> We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt.
Just "1MLOC JavaScriptCore wrapper" is enough to figure out why.
src/ 143k
lib/ 127k
test/ 716k
deps/v8/ 3.6M
Because we have a near infinite number of artificial monkeys figuratively typing at a computer keyboard and, once in a while, they spout out something that looks like an acceptable program.
But it's not acceptable: it's sloppy-pasta.
> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
Yeah. I don't know if we live in the same world as some other HNers: I pay not one but three AI subscriptions: Google (through Google Workspace), Open AI and Anthropic. I'm switching from Claude Code to pi.dev atm.
I'm using LLMs daily. The person next to me too.
LLMs produce shit code. Pure unadulterated shit.
They're extremely useful for many things, including finding bugs. But, to me, they simply suck at fixing them. They write horrible, verbose, code full of bogus assertions and cases that are not handled or not handled correctly.
I do verify the output they produce: the number of time it "works" but I look at the code and see sheer horrors and say stuff like this: "wait, if you replace A by B like you suggest, shouldn't thing X that A makes be done too?". (it's a rethorical question: I know I'm right).
"good catch".
No. It's not a good catch. It's a totally obvious catch that any programmer who's been in this since more a few years (a few decades for me) would catch instantly.
Now if there's one area were they're semi okay'ish is for porting code from one language to another. At least you get a base to start from: if you're lucky. And I suspect it's only looks good if you don't know much about the target language.
Also don't be fooled: we're talking about a company with tens of billions investments that fully knows AI is not enough. You can be sure there are countless programmers fixing, behind the scene, the sheer mess that their AI (with unlimited budget btw) is creating. And then they pretend it's a 100% automated AI rewrite.
AI is not only definitely not enough: it's useful for finding bugs, it's a good rubber duck, but the more and more time passes, the more I'm appalled by the shit code it produces and by the errors they make all the time.
If I wanted to be facetious I'd say that at least we're already --how things moves fast-- long past the point were the kool-aid drinkers explain to us that these thing are intelligent.
It's summer 2026 and, as I type this, the SOTA models all suck at writing code.
Am I still deep into it? Sure am. For basically everything but coding (finding bugs, documentation, translation, generating assets, automating dumb stuff, ...).
Oh well, going back to pi.dev facepalming myself and rolling eyes. I know it's going to be "good".
It’s inaccurate to call it a rewrite. It’s more a transliteration - it matches the original Zig almost exactly but the syntax is different.
And yeah, unsafe blocks anywhere that rust would have complained
So it’s highly likely that the “rewrite” is exactly as reliable as the original.
(It sure feels like this was done for Anthropic marketing reasons, the more I think about it.)
Are LLMs better at writing Rust than Zig? I'd assume so, there's way more Rust open source code than Zig. And if so, that's a very solid reason to switch IMO.
As far as I can tell No one from Zig community got triggered by this other than the Zig team. People were angry about Bun switching to Rust not because it is abandoning Zig, but this reckless behaviour of not letting users know up front, no migration path or two parallel version testing and basically trust AI on everything.
The internet was pretty much on Zig's side or at least between Bun and Zig they were Anti-Bun for a lot of things. That was until Zig's reply.
people chasing after "one shot" code certainly aren't helping, I agree.
- Why would we do that?
- This seems pointless.
- This is fucking dumb.
No, this is a classic mistake. The value of a project is in the instantaneous utility it provides integrated over time. Some things are valuable because they are throwaway single shots that do a thing that's hard. In the past, making those was too costly for the value, but as software drops to near-zero in marginal cost they're worth doing.
e.g. the costco receipts site involves clicking through to view receipts and only 10 'view receipt' buttons per page. I might have stuck it out in the past, but instead I just described the problem to my claw-like and gave it my user/pass and it found it for me while I was dressing the baby. It wrote some Playwright code and this and that and drove the browser interactively.
That code is throwaway code but it was quite useful.
That which can be created with little effort can be dismissed with little fanfare, since it can easily be recreated later if there's a need.
The other category of AI abandonware is one-off stuff. It did its job and there's no further use for it.
> Existing Zig codebase has seen X amount of battle-testing. Rust rewrite: 0 (except -I'm assuming- passing test suites).
Not taking a side here in the whole Bun vs. ZSF dispute, but isn't the entire selling point of Rust that you get a bunch of battle-tested guarantees simply from compiling the program? Is there even a metric for battle-tested? I would say something like sqlite is battle tested vs a vibe-coded network server in c, but does that mean rewriting anything in rust truly mean starting all the way back at square one?
Also, didn't Anthropic roll out a version of CC using the Rust rewrite of bun? Surely they didn't just say "works on my machine" and chuck it into production?
Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?
Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.
Battle-tested, mature code > fresh rewrite.
Existing Zig codebase has seen X amount of battle-testing. Rust rewrite: 0 (except -I'm assuming- passing test suites). Also:
"this was a port to unsafe Rust, allowing a literal file-by-file migration to minimize risk"
How is that better than the Zig codebase you started with?
Now if that's further migrated to safe Rust, put into production & gathered feedback from lots of users, yes then you have something. As it is, the impressive bit is do such a big rewrite & result seems to work ok. Are Bun users happy with this?
To me it reads like Bun was forked. Will the Zig version survive? Will the Rust one? Both? All options ok.
Edit: and fwiw, I don't think Zig community should get triggered on any of this. It says nothing about how suitable Zig is or isn't for project xyz, and Zig community is big enough to carry their own project & applications besides Bun.