They get abandoned because they get generated on a whim.

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.

> Now if that's further migrated to safe Rust, put into production & gathered feedback from lots of users, yes then you have something.

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.

> How is that better than the Zig codebase you started with?

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.

> There's so much good stuff in this post.

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.

But it’s really the same old problem we’ve seen for decades. Developers write code. Owners declare victory. Owners rid themselves of expensive opex. Owners sell the division or try to keep the project limping along but all they see is vaguaries from the new cheap guy who they keep telling isn’t good enough for a raise, company hemorrhages money and eventually sells for a song.

They’ve just found a way to explore that logical fallacy even faster.

the rust is merged into main https://github.com/oven-sh/bun

and the rust version has been live in claude code since june 17th.

> 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.

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.

I read a decent chunk of the rewrite.

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.)

> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

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.

Rel: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

>I don't think Zig community should get triggered on any of this.

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.

>Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

Because most projects are abandoned within months. Why should they be any different in that respect?

> Are Bun users happy with this?

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_...

Yeah, I was just commenting on a LinkedIn post[0] (don't hate the player, hate the game :) ). In it, someone talked about the difference between creating software and owning it.

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 don't think Zig community is triggered, I think only Zig's creator is triggered because he is afraid of people interpreting this as "Zig is unsuitable for X".

I think a lot of people will, but those who do probably weren't the target audience for Zig in the first place?

I've run into a bunch of segfaults in Bun whenever I went slightly off the beaten path, probably from the "horrifying" Zig code. A huge test suite + a clean rewrite with a path towards more safety is how I would go about it too, personally. Now whether I would do that rewrite in Zig or Rust, I'm not sure. But I have high hopes it's going to work a lot better, especially since Anthropic uses Bun heavily.

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.

I think the mistake people are making currently is that they publicize stuff way too early. I.e. they make a prototype and then put that out there. Possibly with a full product page and all.

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.

> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.

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.

> To me it reads like Bun was forked. Will the Zig version survive? Will the Rust one? Both? All options ok.

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).

I think the line is between AI-generated and AI-assisted - I have AI assisted projects that I have happily been developing for several months and they are going fine, I feel just as engaged with them as I did with my hand coded projects, but also I am more engaged insofar as I actively manage the architecture and the code, and see to it that the AI is following the plan I have in mind.

people chasing after "one shot" code certainly aren't helping, I agree.

This is why IBM still sells so much ancient z/OS mainframe code, things like CICS are the most tested code in existence.

> Because value of a project is not in the code produced. It's in the amount of battle-testing that code has seen.

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.

Its true about the battle test

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?

I don't even get what they gain by Rust - Bun imports Webkit, which is a C++ project, relying on it for stuff like JITing Javascript. I would say that's a major concern, and making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust.

I've always viewed unsafe Rust as a sort of last resort you use when you just can't do something safely. Porting something to "unsafe Rust" to me feels pointless, and of course this hasty rewrite was probably not the best idea from any perspective.

Of course the deeper points can be made that relatively few folks were actually using Bun. After all Bun was itself a faster horse compared to the dominant runtimes it was aiming too replace. Ironic, the way this whole meta conversation is playing out.

That battle tested bit is so true, always was. It’s hard for engineers to admit their hard work is worthless until they have let other people use and shape it.

Honestly I also think most vibe-coded projects are just.. kind of bad ideas. Which is fine! It's good to be able to determine an idea is bad quickly, there's value in that, but I think people ignore a really important aspect of creativity: the insights you need to have a good idea come from struggling in the muck and struggling in the medium. It's really hard to have good ideas from an ivory tower, you need to get into the details.

> 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).

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?

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.

That's such a bad take. You mention some good things they need to do but ignore the part that those are next steps and will take time.

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?

> Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why?

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".

[flagged]

It's more than just the battle testing. Things that are not wanted by a community or by users are not important. AI delusion memes are fairly reductive but a commonality I see in many overtly ai evangelistic groups is an urge to build without motivation and agreement. The yes we can answer AI gives to user's every question is a failure mode trigger. LLMs are missing the filter an engineer with a human body may give you to an idea...

- Why would we do that?

- This seems pointless.

- This is fucking dumb.

Totally disagree that the value of a project is it's durability. The value of the project is almost entirely disconnected from durability. Value is simply the ability to solve a problem for you. I'll use a bad screwdriver before I use my fingers, even if I prefer good screwdrivers.

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).

I guess the Rust rewrite is the exit path of the Bun's author so that the others could "handle" the code base.

> How is that better than the Zig codebase you started with?

It's not better, it's worse given the average bear's assumption about a rust project.

"How is that better than the Zig codebase you started with?" - It will be worst, as this will not be idiomatic Rust. That's kind of interesting, BTW, as in next iteration LLM will be trained on tones of crappy code, created as some random rewrites, AI slops, etc., I am curious if someone will be able to curate this or it will be the same process of crapification experienced by Google Search that finally lost the battle with SEO spammers.

> How is that better than the Zig codebase you started with?

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.

>When I read the post, my first thought was that I wouldn’t want to build things in Zig, because any technical decision I make, good or bad, might subject me to this kind of article from their BDFL.

I think it is worse than that, the comments from people in threads about this suggest that this is an attitude that is creeping into the community. They may not be a majority, but if kinder souls decide to leave for a more welcoming community, the remainder will be more concentrated.

> The bigger problem with the post is that it talks out of both ends of the mouth: it’s clearly meant as a personal attack, but also insists that it isn’t.

my instinct is to step up and defend Andrew: to say that truly, he has strong opinions -- which is to say he _cares_ about doing things right -- but that he's more patient and accommodating than you're judging him to be from this 10,000ft view.

that's kinda weird: you might view this as a personal attack _from_ Andrew against Bun and i might view the reactions as personal attacks _against_ Andrew. viewing it through this lens without our preconceptions ought to make either both parties or neither party look bad, i think? i don't know the solution except to highlight the outsized impact that our individual preconceptions play when judging a situation from 10,000ft away.

If you don't intend to write misleading stuff that makes Zig look bad when you leave and if you avoid ghosting the Zig foundation in scheduled meetings you had with them, I suppose you should be good.

> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.

At least for Rust, part of this is because there is no BDFL, by design. Python has moved away from the BDFL model as well, IIRC. Individual contributors can get mad and write angry personal attacks, but there’s no face of the language like there is with Zig.

It might be helpful to read the latest revision of Andrew's post, which may address this concern for you. It received several revisions: https://github.com/andrewrk/andrewkelley.me/commits/master/p...

> I can’t conceive of the leadership of the Python or Rust or any other community I’ve ever worked with doing something like that.

I'd be prudent to use a clear faux-pas by a BDFL as an argument to push for an alternative, seemingly more consensual, leadership style. I'd also be careful to fall for the apparent lack of overt aggression in the latter type of structures, as a necessarily positive signal. I've seen people in various such communities (including the two cited languages) that have chosen not to interact with their steering committees, because of perceived toxicity.

This can and does happen with any kind of structure and can take many shapes, some of whom are too subtle or passive to even accurately pinpoint, in the way you would for example directly index a BDFL. In The Tyranny of Structurelessness Jo Freeman made the case that the lack of a clear structure in the make up of a movement presents with opportunities for very fuzzy power dynamics and related abuses that are also much more challenging to deal with.

I appreciate having an opinion vs a bunch of safe words saying nothing. Most CEO communication probably isn't even written by them and has a person-less touch.

It's totally fine to get a negative reaction and avoid the project. It's called having human emotions, which is actually healthy. Getting feedback is how you learn and grow as a person.

To me it's just highlighting the reality -- Anthropic fired the first shots. I think it's reasonable for people to say, hey, if you're going to trash the reputation of Zig (in a pretend-objective way) then it's entirely fair for people to put in important context that Bun was not written well.

Andrew didn't make the hit piece out of nowhere, unprovoked.

Jared, using Anthropic's multi-billion dollar microphone, painted Zig in a bad light with their first (denied) attempt to merge a vibecoded PR to improve Zig's build times.

Then very shortly after that failed attempt, about 11 days later I gather, Jared (again with help from Anthropic's very big microphone) made public the Zig-to-Rust port.

So unless you're planning on getting acquihired by Anthropic _and_ planning on porting away from Rust using their tools very publicly, I think you'll be safe from such pieces.

[flagged]

Everyone is motivated. It seems to me that Anthropic went out fishing for something to blow up. As Ray puts it: "Management eagerly approved the Rust rewrite option because it was a great marketing opportunity to showcase their new Fable model, Anthropic already uses Rust, and Zig is openly against using Anthropic’s products." Sounds spot on.

Others have pointed to some plausible technical benefits from the port, namely that it forces an enumeration of unsafe code boundaries. There's probably something to that, but the big idea is that Anthropic bet that its models could do a big job, and they needed to both demonstrate that and make hay of it. Everything aligned. They did the port. The artisans might call it slop, but it runs, they did it like 2 weeks, and they stuck it to the guy that shuns AI.

If you're the type of manager who picks farming out work to a body shop with 100 unskilled workers instead of hiring 2 legitimate FTEs, then this is speaking your language.

I had this exact same reaction. Agreeing with the substance of the critique of approach etc but not at all its tone nor of the underlying elitism that lays there.

This is not how professionals behave in a profession.

Decorum actually matters.

Anthropic is doing bad stuff. They clearly have a broken internal engineering culture. Hence I don't use their products. But I expect to see this laid out in a structured argumentation that doesn't go after people and their personalities.

> But I'm glad he stayed honest to himself instead and didn't have a PR team ghostwrite his thoughts.

If there's one thing I learned in this debacle is "I should spend 1-2 days and send to a close friend before hitting publish on a firey reply." The way Andrew rephrased the closing section is the kind of thing I should publish on the first edit in similar scenarios.

Wankfluencer has now been added to my lexicon. It's a word that feels like it should always have existed, but didn't. So very aptly describes these personas who would pimp their own mother for a t-shirt with a logo on it.

It was poorly justified up-front but frankly I did not need the examples to understand Jarred’s frustration.

What I found helpful were his explanation of how the interaction with JavaScript’s garbage collector created unique challenges for Bun. Andrew did not address this point at all. It was also helpful to understand how the test suite covered the new code - many people had assumed the tests were also vibe translated and couldn’t be trusted. Andrew pretends he didn’t understand that tests don’t catch all bugs, which is true of all software including Zig.

To me this whole exchange is mostly the typical “memory unsafe languages lead to time consuming and disruptive defects that can be almost entirely prevented with a choice of programming languages” versus the “git gud and don’t write bugs” response.

Layer on the AI tension, Anthropic’s involvement and Andrew’s classic Linus impersonation and of course its viral.

>Call a spade a spade, the rewrite was poorly justified

In what world do you think they have to justify a rewrite to anyone outside their company? Bizarre mentality.

i appreciate people saying it like it is.

like linus lol

i hate marketing pr speak when it comes to technical things.

save that for the non technical customers

[flagged]

> psyops Dario and co. cooked and delivered

Does that include Claude itself? Half joking aside, my main concern remains that both OpenAI and Anthropic practice this fear mongering as strategy at the executive level because they have to. A corporation is a different beast. Not human, exactly. Not AI either. What happens when a corporation starts being informed by the AI it is building?

If you want a lens into master craft corporate human slung bullshit, read this: https://www.theverge.com/podcast/944138/microsoft-ai-ceo-mus...

In this, not only did the interviewer admit he knew Suleyman had written about the issues he talks about in his rebuttals, he then says he's only asking (the hard question) because the "audience" wants it.

Suleyman's response talks about taking "accountability for the things that we build" and the "types of problems that we choose to work on," it highlights the fundamental flaw in the cloud-rented AI model.

In that ecosystem, "we" means a handful of corporate executives deciding what tools the rest of the world gets to use, how they operate, and what data they extract. All based on the profitability of the corporation. It is the absolute antithesis of a sovereign architecture where execution happens locally and the user dictates the terms of the system.

They are coming for open models. It's time to harden the gates.

> Anthropic is not in the programming language market; their post about rewriting Bun in Rust is full of technical details that led to improving the end product for their users

Anthropic absolutely is in the programming language market. If/since AI makes rewrites to certain languages relatively easy, a success story will tie the given language(s) to the given AI company.

Rust may have a tremendous success in the future, because it's much easier to write it with AI (ignoring for a moment whether that's really a good thing). The implication is that Anthropic has a stake in Rust's success.

Also, to be kept in mind that devs advertising successfull rewrites often hide some aspects that are unfavorable to the narrative; typically, how bad was the code before the rewrite), although there are other (significant) aspects that have been omitted.

> Zig's response is a sour opinion piece full of personal attacks.

I take you haven't read Andrew Kelley's article (here: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...).

Summary:

- Jarred has written Bun with very bad engineering standards

- Jarred has managed public relations very poorly (e.g. ghosting the Zig foundation)

- When they rewrote the project to Rust, and described Zig as poor choice, there has been a negative fallout for Zig

- The ZSF is obviously upset because of the poor publicity

This is summarized at the end of the post:

> Zig users who knew next to none of these facts and have only the surface level understanding that an ex-Zig-user is getting trashed by the language creator. Such people might reasonably worry that might happen to them

As a matter of fact, I also believed the same after reading's Bun's post. This is undeserved though, and that's what Kelley explains.

There's definitely a personal attack somewhat, and this is addressed in the last (added later) section.

Yeah, exactly. It's weird that Zig even responded to that. Imagining that your studio switched from Unity to Unreal and Unity proceeded to release a hit piece attacking your codebase quality and workplace environment.

It's the old craftsmen vs industry issue, Andrew comes from the craftsman tradition that prefers all other people developing to also be proud craftsmen.

What Java, JS, Python and C# all did to conquer the industry from a C++ dominance was to provide safety harnesses for less "perfectionist" workers to fumble around without causing a mess, to write C and C++ in an increasingly hostile world we realized you needed a lot of craftsmanship, the performance benefits outdid and kept the latter languages relevant for a long while.

Still, the performance/predictability penalty didn't give way so Rust (and Swift) came into play. They don't have as many unpredictable performance characteristics as the previously "safe" GC languages but still provided more or less the same guarantees (in some ways perhaps even better for Rust).

The brilliance of the Rust ideas did start a bit of a cambrian explosion of languages in that niche, most of them however targeting a bit more of a craftsman position than Rust (that came out of distinct industry needs).

The problem as the article illustrates, in car terms.

If Java,JS,etc are mostly "regular safe cars" and C/C++ a two wheel motorcycle.

Rust is perhaps a rally car (fast but still a car so occupants inside are well protected) whilst Zig really is a quadbike or open wheel cart, not as unsafe as a two wheel bike since you won't slide for the smallest oil/ice patch but flipping over is still dangerous as hell.

And that takes us to the crux, so many developers who love the craft and perfection (and don't live under- or perhaps care of- financial constraints) think that "good careful" developers is all that's needed and don't see dangerous language designs as a problem.

I'm an older developer, and given that I can write "good careful code", but 90% of the time it's also a matter of time and financial constraints so I wouldn't trust mine (or anyone elses for that matter) code written under those "industry" conditions.

I think Zig has a lot of nice perks, but it was obvious from day 1 that it's very much for people that love their hacking freedom over writing code for todays hostile world.

The results improving the end user experience didn’t have much to do with the rewrite. Improvements in binary size and speed could be had with similar efforts on the Zig codebase. They spent extra effort to get those metrics to look good to sell the rewrite.

The memory safety aspects could be discussed. Arguably they could have had equally good memory safety by employing AI, tests and fuzzing (the Zig integrated fuzzer that the Zig team suggested they use, not just the high level fuzzing they were doing)

For this kind of project I do think using Rust is a good idea. At the very least because a project like Bun probably can benefit from a more mature language.

But I also think Andrew’s perspective of this process has been essential to understand what happened here, and though he could have been nicer with his word selection in a couple of places (he doesn’t have the clout of Linus Torvalds to get away with it), what he wrote absolutely needed to be said. I find it annoying that people dismiss it as personal attacks. If being a bad manager is the direct cause of a poor working relationship and bad engineering results, pointing it out is not a personal attacks. It’s essential context for understanding what happened.

> Anthropic is not in the programming language market

Arguing that a product that sells itself as improving programmer productivity by writing the code for you has no stakes in "the programming language market" because it doesn't sell a programming language of its own is impressively shortsighted. Especially when the leader of a programming language has openly stated their dislike of vibecoding, critisized the industry, and the language project itself rejects PRs made with the product being sold.

Yeah I don't understand these myopic takes.

Jarred's post about Bun-Zig-Rust post was technical and polite.

Andrew's post in response was anything but that.

I'm a heavy Rust user who doesn't like Zig all that much.

I browsed through the Bun code following Kelly's post, and decided to have Codex replace all my Bun usage with Deno.

> Anthropic is not in the programming language market;

No, they're intentionally in all the programming language markets.

> Anthropic is not in the programming language market;

Did we just read the same blog post? I see no assertion in it that Anthropic is in the programming language market, rather that this rewrite was a marketing opportunity for them they were happy to lean into.

> For context, I'm using Codex and have no interest in either Zig or Rust, so just observing this drama from the sidelines.

The latter part of the post is much less about Anthropic and more about AI coding in general so I’d say it’s still very relevant to your interests.

Did we read the same Anthropic and Andrew Kelly's posts?

Anthropic's posts were sanctimonious, self-serving, tone-concealed delegitimisation of Zig. Kelly's post was a strategically poor but sincere individual understandably frustrated at this concealed attack, expressing his honest feelings about the situation.

Yeah and Bun and Zig are not competing in anyway as well. Zig blog post has been updated as well recently btw.

> Anthropic is not in the programming language market;

The article by Ray Myers makes the case that Anthropic is in the programming language market by way of them having a clear monetary stake in making their agents look supremely capable of all tasks, up to and including rewriting an entire Zig codebase to Rust.

From TFA:

> Anthropic is actively campaigning to end software engineering. They need you to believe they can do that. Well, maybe it’s not you that they need to convince. Maybe it’s your C-Suite, various world leaders, or the manager of your retirement fund. They’ve raised $132 billion in investment, and are approaching an IPO valued over $1 trillion. Since they cannot show profitability, this depends on selling their hypothetical future impact.

> In literary terms, Anthropic is an unreliable narrator.

> One of their key narratives is: Coding is going away, then the rest of software engineering, and eventually most other human labor. This kind of money behind this kind of story has an impact, regardless of how true we think the story is.

The moment technical decisions are influenced by LLM compatibility and LLM performance, they basically are.

Remember the days where teams would adopt technologies based on how familiar the members are with them? "Now that the AI is here" and is the one writing code, to the point where Linkedin devs flex how it's been months since they touched source code, teams adopt technologies based on how familiar AI is with them.

Andrew Kelley mentioned that the rewrite did bring technical improvements, however those were not tied to Rust and could've been made in the Zig codebase.

> Zig's response is a sour opinion piece full of personal attacks.

Not sure; it has some elements of personal issues, but they're followed by a rationale from the author.

Honestly, seeing the project lead (Andrew Kelly) take a stand against poor engineering practices without any equivocation makes me more inclined to want to use Zig - their values (in this regard, at least) align with mine.

He also substantiates what many of us are saying to all these "Very Senior Chief Engineer with 40 years experience" who are boasting of 10x productivity: these people aren't reading the code they are generating, and were producing slop even without AI.

You mean Anthropic has no agenda on its own? That seems a very biased analysis here. The response by Zig could be flawed (speculation, I have not reached this conclusion yet) but I don't see how this offsets Anthropic wanting to promote its AI slop here in any way, shape or form.

Stating you use Codex does not add any meaningful information to the case.

The facts as presented from the Bun side show a lack of technical merit for the rewrite. This shouldn't be surprising, because rewrites are bad engineering, in most cases.

The Bun project was started in Zig by someone with a lack of experience using the language, despite the massive scope and complexity, and was effectively a rewrite from another language in the first place.

From the Bun post:

> Bun started as a line-for-line port of esbuild's JavaScript & TypeScript transpiler from Go to Zig.

Then, a few years later, the entire codebase was thrown out to do another rewrite in another language.

What is there to address?

Andrew essentially wrote that “bun code was bad anyway”.

And also he implied he doesn’t even want to engage with anything relating to this since Jarred is toxic and there is no value in the debate.

I think these points are fairly clear from his blog post

the best way I've seen it described is like this: Bun wants to move fast and breaks things, Zig forces you to move slow and carefully.

Bun wants to ship new features ASAP (a shell lang, sqlite/pg client, etc), so they'd really want stuff like memory management out of the way. Zig forces you to think and deal with memory management, lifetimes, etc. Rust is just a better fit like w `Drop`, and Zig explicitly won't add `Drop` or anything similar.

Just like I wouldn't write a SQL database in Python, Zig is not the right tool for Bun. So there isn't really anything that "should be solved in Zig canonically". I'd say it's more in how Jarred want the project to move forward. Move fast and break things.

TFA article addresses this directly. The write up is good but it is selectively written to contain almost exclusively positives.

Like build times: they rewrote the Zig compiler to improve them, but Rust build times are typically much slower. Why no discussion of that at all?

> I don't care that Anthropic sells shovels in the gold rush

The people selling shovels are the ones building data centers and energy. Tokens are the "gold".

> What I have been missing in all this debate is substance.

That’s strange because in this (and Andrew’s in lesser extent) post there’s plenty of substance on both technical, management and corporate influences like the difference of styles guides vs agent instructions, binary size, compile time, Anthropic’s marketing and incentives, etc. It’s hard to miss.

I don’t understand why anyone thinks management of any kind was involved in this at all. It seems much more plausible to me that Jarred just does what he wants. He has said as much.

>very actual technical substance

Did we read the same article? I mean it wasn't talking about a specific line of code, but it had deep architecture details, rational for memory safety and bugs, agentic coding patterns for scale. It was full of substance, multiple times.

TFA has an odd perspective.

> Views are my own. I have no history with Zig. I’ve never spoken to Andrew Kelley

There are better primary sources to explain what ZSF is trying to achieve with its AI stance. Kelley's rant [0] was a bit much but the ZSF AI Policy [1] and Kelley's interview on it [2] are interesting and informative.

[0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

[1]: https://ziglang.org/code-of-conduct/

[2]: https://www.youtube.com/watch?v=iqddnwKF8HQ

Yeah, hard to imagine opposing AI absolutists settling their differences.

IMO all the technical arguments and attacks are post-rationalization; different orgs, different contexts, different goals.

I think Kelley saw this, but couldn't resist muddying his point. I give him a pass. The rant [0] is too much, but the addendum about moving on is healthy, and I'd rather the BDFL be too spicy than not spicy enough.

[0]: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...

Funding and owning something makes you accountable yes, that's how it works normally.

>As for actual coding… LLMs will always do better work in a well known stable language than something relatively new.

Say that louder for the people in the back, who still think that LLM companies don't influence the entire programming language and framework field, by merit of the fact that LLM's can only perform at scale after lots of training.

And when we reach the point where source code doesn't need to be read, said companies will vendor lock you even harder by marketing their own LLM-optimized language and framework, promising everything and the moon in terms of productivity gains. First class support was the reason they acquired Bun.

> can I spend a few thousand in Fable tokens and ship DinnerRoll( Bun in D).

Probably. Likely would work with sub fable class model too.

> Is that enough to raise a VC round?

Doubtful. Think this move only works for someone with an existing product and following

> but do people blindly trust them

Judging from internet posts and HN comments, many do.

It's a big precisely because so many people are blindly trusting AI company marketing. It blows my mind how many people, especially here on once-subversive hacker news, are not just swallowing the marketing but they are doing the marketing for these companies for free. That's why it needs to be talked about!

If left to my own devices, I can code 12-16 hour days. Have a crash day every 4-5 days, and then go back. It would be extremely unwise to merge even half of that stuff. I would frequently throw it away. Even before AI. It would be extremely naive to think that I am productive/efficient or responsible or a hard-worker for doing this.

Hey, I can party the way I like to party.

(I am old enough to catch myself and stop this cycle now)

Edit: I was super impressed with him in the first 10 minutes. It’s very Knuth-like to create a programming language because you had trouble building an audio system.

Nobody and nothing is fluent is "web tech"!

I'm left with a good impression.

Lot's of comments on the whys and historic context.

Backed by tons of tests.

Yes the file could use some modularisation and splitting into smaller parts but maybe the gains were weighted and judged against.

That file is a great example of KISS.

Because underneath the code you have more than one architecture to support.

I think this post completely destroyed anthropics narrative

Probably because agents in typescript don't waste time reasoning about so many different problems that come up in a lower level language. They stay higher level, and don't waste context on thinking about borrow checking, like you would in Rust.

Pretty sure this section’s title was “Say something nice”

…he had to resort to AI for this part.

Why would the author write this paragraph alone using AI?

Well, I see LLM coding capabilities as a great enabler for people who have some codeing-like skills or needs, but were not sufficiently skilled to do something more complicated. Think of people who are good at Excel, who use statistical tools like SAS, SPSS, other analytical software. Now they can ask LLM to create a Pandas/SAS lang script and do much more advanced stuff.

People who were in the marketing data analysis (like sentiment analysis) - 5 minutes and they have a code that uses Hugging Face model suited for sentiment analysis, zero-shot classification, etc. No need to pay for expensive online services or expensive NLP software. It's here for free or $20 a month.

Still, it does not mean you will be able to code database engine with LLM, application server, rewrite Django in Rust, etc. So software engineers still will be needed to do ambitious, complicated stuff.

So, I kind of see it backwards, real skills, like knowing algorithms, understanding performance (including hardware stuff like processor caches, etc.) will become needed, as other, simpler jobs that needed only a "coding monkey" will be gone.

We no longer need to dig ditches manually, we have machines for that, but the purpose of the ditches is still planned by man.

This is quite true. Also, there is no project you can make as a junior to demonstrate your unassisted competence because 10 other people used AI for a similar project

> Zig creator's article seems to have changed? I don't remember the bottom bit being there when I read it a few days ago.

Yes, Andrew edited it. Diff here: https://github.com/andrewrk/andrewkelley.me/commit/8b86ac915...

But, but, how do we get to experience emotions otherwise? We have no life!

It should have been possible to build a new LLVM alternative, a new chromium like browser and some other similar things imo and that would have been definitely more impactful for me.

It is unimaginable how many static analysis tools or fuzzers could have been created with a fraction of LLM investment too.

For example honggfuzz was created by a single engineer possibly in less than a years’s worth time

> The more I interact with the real world and mature as a person

I don't think this statement has the effect you want it to have. You're not laying out the experience you're speaking from. You're just setting it up so that no matter how reasonable the next thing you say is, it will appear maximally arrogant and condescending.

Good grief! I can count at least 6 logical fallacies in your 3 sentences.

> I remember the uber db migration post and I can't help but wonder if the tone of these conversations would be different for bun if AI wasn't involved.

Another point of view is that, if AI wasn't available, pre-port Bun wouldn't have been such a total mess that even Fable couldn't unfuck it.

IOW, the Bun codebase was being vibed well before the port; if AI was not available, would Bun have been in such a poor state that a rewrite was even necessary?

The AI panic has infiltrated the space now, and it’s just as bad as the AI hype. Half formed ideas, emotional posts with personal attacks and arrogant language, exaggerated claims, posturing, etc.

In the meantime, most of us are just using whatever tools are at our disposal and minding our own business.

Anthropic isn't selling that, that's the point. Anthropic is selling "coding is solved", worth $1tn.

If they keep hiring developers and LLMs need huge procedural harnesses, then the hypocrisy is open for all to see. And worse for them, it probably means their business model is worth maybe 5-10x what Jetbrains is worth, not $1tn.

Umm, yeah.

Obviously the neckbeard who wrote C in vim and compiled when he is done is a better coder than the one who kept compiling and fixed issues when told by the compiler.

> Just because people can get away with using AI to make A apps that are "good enough" or pass test suites

That requires some proof, because the trend is that users of A apps dislike the lack of engineering that comes with AI involvement.

> why are Anthropic rewriting a Javascript runtime from Zig to Rust?

there is a chance they tried..

My experience was that LLMs performed at Zig and Rust at about the same level? That is: worse than at something like JS or C or Python, but well enough to write code that works. And they only got better since I first tried them.

Intuitively, Rust would perform worse because ownership is a different paradigm, while Zig is far more similar to things like C/C++. But I guess that's canceled out by the disparity in the language resource base.

If we expand the placeholder, I think "Anything that can be rewritten in a language with excellent performance and safety characteristics will be rewritten in a language with excellent performance and safety characteristics" is a desirable state of affairs.

> Oh, they're converting Bun to unsafe rust. That's easy, but useless.

You really need to escape the Zig vs Rust language wars bubble to get a real read on what Bun was doing.

They started by attempting a more direct translation. Not quite transliteration but close. At this stage they wanted to bootstrap the codebase into Rust as quickly as possible using parallel agent sessions, which requires minimizing the number of refactors that cut across the codebase. After it was bootstrapped into Rust they continued on the rewrite to take advantage of Rust’s features.

The anti-Rust side has been clinging to that first step as evidence that it’s all broken, ignoring the fact that it was an intermediate step.

The “unsafe” part is also confusing a lot of non-Rust devs who don’t understand that unsafe is used in cases of crossing FFI boundaries, which Bun does a lot of by nature

Isn’t the point that it doesn’t matter if humans can work on it, as long as the AIs can?

> That's easy, but useless

The Rust toolchain is a delight in comparison to Zig's, and the unsafe code only need be temporary until humans (or, gasp, AI) address each class of underlying issue.

This is a no-worse-off state to improve from.

[flagged]

Keeping it to the most mainstream, Java is a mighty fine choice as well, with even better options for third-party packages, tooling, integrations, and telemetry than most of the above.

I think Odin's batteries included approach have a chance to achieve escape velocity.

Specially if their community and their BDFL continues to be welcoming and fun to interact with.

Their 1.0 roadmap announcement is cool: https://youtu.be/dLPAqXi9In0

Here's most of the language in a single demo file: https://odin-lang.org/docs/demo/

Forgetting the JVM when it provides absurdly good performance and more packages than pretty much all three of these languages combined is certainly a choice. Even Java and all its verbosity gets fixed by not having to write it manually. Kotlin is also a very viable option. Scala if you're a bit crazy.

Why would you need any of those listed capabilities these days? Just generate them with 100x AGI

I love how many people are tech prophets now

But fair?

> Completely shutting out one side of the industry and taking a dogmatic position is not helpful, especially for a pre-1.0 language that is still relatively immature.

It is useful, you just have different goals in mind than the Zig leadership. Zig shared their detailed reasoning for that decision, which is mostly about the development and protection of the community

> If the project accepted AI-assisted contributions, this controversy might never have happened.

Had I given my wallet to the thief, this controversy (me getting stabbed) might never have happened.

This 100% was a way to getting back at Zig for not allowing their parent company's product, and a marketing move for Fable.

I'm on the same page with you that their AI stance is probably harmful for them -- but I think they wrote those as a reaction to the contributions from Bun and others. So your implied timeline is not entirely correct.

> The post claims they were fuzzing their Zig code, while during our calls the whole Bun team told us that they were not fuzzing anything

If you read the post again this sentence is not removed and Sumner did not refute that

I’m puzzled by how many people seem to be convinced (deluded?) into believing that their productivity has been multiplied and costs have become fractional to build things, why don’t I see any of that productivity gain or cost reduction out in the world? What has become cheaper or better engineered? If you believe posts like thsi, we should be living in a golden age of prosperity, when it seems that aside from getting better lots of products and companies seem to just be getting worse? Like seriously, to a normal person, putting aside from the benefits of using LLM’s directly for the LLM user, what things in the world have gotten better thanks to this abundance and oversupply of “intelligence” that is supposedly mutiplying people’s productivity?

You have a very fitting username

Not a lot of it is unsafe, I think they said 4%?

It's practically impossible to write safe Rust when you are calling external libs written in C/C++, like they do for the Javascript engine.

IIUC that was meant as an intermediate step (which isn't uncommon), which IMO makes the translation way less exciting.

The interesting part will be whether they can transform that "mechanical Rust" into something idiomatic. I'm waiting ...

Unsafe Rust makes me think they did this entirely because LLMs are better at Rust than at Zig, but let's see what happens next.

Rust Bun has been running Claude for some time now.

I'd be inclined to trust production code in such a large usebase.

What do you mean? It's literally been a significant part of their marketing.

Wat?

Anthropic leadership, including CEO Dario Amodei and co-founder Boris Cherny, has declared that software engineering is dead or will become obsolete within 6 to 12 months due to AI automation.

Cherny states that at Anthropic, no code is manually written anymore, with engineers using Claude Code to generate 22–27 pull requests daily and AI agents operating in autonomous loops.

https://www.reddit.com/r/BlackboxAI_/comments/1qxhqry/anthro...

Probably just you. I use them somewhat frequently to make it clear where a set breaks down into alternatives or parallel factors. If there's a preface and trailer around a list of complex items, I think writing the list in one paragraph is often ambiguous and hard to follow. Using a bullet list within that kind of paragraph (IMO) makes it easier to follow what I think is important.

Well, yeah, most social media posts that contain a list or a table these days are ai slop.

> The whole point of the borrow checker is to make it impossible to write wrong code.

> In 2026 we need guarantees that we can't produce invalid code.

Rust doesn't provide either of those guarantees.

If I were to rephrase your sentiment for accuracy: Rust disallows certain coding patterns. Certain classes of bugs can only appear in those coding patterns.

IOW, Rust disallows $FOO which is a superset of "specific class of errors". This means that while Rust prevents specific bugs, as a side-effect it will also prevent some correct code.

The borrow checker is a good tool (and it makes Rust objectively better than Zig to me), but it unfortunately doesn't prevent writing bad code

An issue with Bun is that it interfaces with a C++ JS engine and it needs unsafe. In this case, the best practice is to write a safe binding to encapsulate this external dependency (that's why in Rust we have -sys crates with raw unsafe bindings, and other crates with a safe interface on top), and then write your business logic entirely in safe Rust

However, the Rust port of Bun didn't follow such best practices (perhaps with good SDD practices it could, not sure about that). The resulting code has literally thousands of unsafe blocks. It also contains plenty of UB. The port already costed hundreds of thousands of dollars. It's unclear if Mythos/Fable is able to refactor it further to remove unsafe usage without introducing further UB, and how much it will cost

(here It's important to note something. Rust UB is in some abstract sense harder to deal with than C or Zig UB, because it also needs to uphold the guarantees of safe Rust. If you get to write your business logic in safe Rust that's a good deal, but the price of that is that your unsafe code has extra responsibilities)

Rust requires discipline too. I can go around using Arc, Rc and .clone() everywhere without upsetting the borrow checker, I can use let mut a bunch and pretend if, match, etc. aren't expressions. This results in worse code, and Rust didn't stop me.

The borrow checker prevents a set of errors from being possible, but it doesn't prevent bad code from being written.

Static memory safety is a spectrum and so is code quality.

> how is that different from C?

Zig gives you far more memory and type safety than C and without a borrow checker and a complex generics system.

Zig also allows optional runtime checks (at the cost of runtime performance).

There is no better language between Rust and Zig because they have different tradeoffs that are better or worse in different scenarios. It is more like Rust vs C++ and Zig vs C.

Most bugs are logic bugs which rust does nothing to help you with.