8 ms·

There's so much good stuff in this post. Can't help to think of a recent HN post about most AI-generated projects being abandoned within months. Why? Because

There's so much good stuff in this post. 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.

herrkanin 3mo ago
> 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.
- cyber_kinetist 3mo ago
  > clear well-scoped unsafe boundaries 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!)
  - baokaola 3mo ago
    There's only one language that's more dangerous than C and that is unsafe Rust. I say that only half-jokingly.
    - Ygg2 3mo ago
      Good job falling for the Zig propaganda. I say that half-jokingly. EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.
      - selfmodruntime 3mo ago
        This isn't propaganda, the Rust compiler's rules when using the unsafe keyword are difficult to uphold, which is why the community wrote Miri.
        Ygg2 3mo ago
        Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? And how does Miri help solve this issue?
        selfmodruntime 3mo ago
        > Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? By the engineer's wit of course! > And how does Miri help solve this issue? By detecting undefined behavior caused by violation these rules
        dwattttt 3mo ago
        Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.
        Ygg2 3mo ago
        > By the engineer's wit of course! 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?
  - lolinder 3mo ago
    No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said: > 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.
    - cyber_kinetist 3mo ago
      > We can gradually refactor it 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.
      - Tadpole9181 3mo ago
        You're not helping your case. 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.
        metoobruh 3mo ago
        You're not helping your case. > [what you just wrote] So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.
        Tadpole9181 3mo ago
        Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine. Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
  - selfmodruntime 3mo ago
    There is almost zero reason for a public facing, non-embedded project like Bun to use unsafe anywhere.
    - cyber_kinetist 3mo ago
      You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)
- petesergeant 3mo ago
  I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.
- lunar_mycroft 3mo ago
  Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.
  - selfmodruntime 3mo ago
    This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.
    - lunar_mycroft 3mo ago
      You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
      - Tadpole9181 3mo ago
        Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?
        lunar_mycroft 3mo ago
        > Which is still a step ahead of Zig 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.
lennxa 3mo ago
the rust is merged into main https://github.com/oven-sh/bun https://github.com/oven-sh/bun and the rust version has been live in claude code since june 17th.
sph 3mo ago
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.
- manphone 3mo ago
  It’s the same reason why everyone doesn’t wanna read LLM generated blog posts. The agreement used to be generally that you would spend more time writing than I would have to spend reading and when the agreement changes the quality changes as well.
  - pydry 3mo ago
    Or rather because they are always just of poor quality
    - pmarreck 3mo ago
      Define “quality” (I’m pretty sure both you and I would “know it when we see it”, but…)
      - lproven 3mo ago
        There was an entire book about that 50 years ago, and last month someone brought that thinking and analysis to the LLM-bot issue: EDIT: this is the one I was thinking of... https://sinclairtarget.com/blog/2026/06/01/quality-in-the-age-of-slop/ 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-generative-ai https://bersas.substack.com/p/zen-and-the-dance-of-generativ...
petcat 3mo ago
> 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.
- ACCount37 3mo ago
  I used to think there's a good niche for "better C" - and that Zig was the one language angling for that. A language that can be used in the same contexts as C, to do the same things as C code, in very much the same way, but with some modern features, some stronger guarantees and some helpful syntactic sugar? A welcome thing for embedded development. 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.
  - ctvo 3mo ago
    I wouldn’t write Zig off yet. The faster compilation time is a giant moat. Depending on how LLM usage evolves it could be what ends up mattering.
    - pmarreck 3mo ago
hypfer 3mo ago
> 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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- Ygg2 3mo ago
  It's funny, but I think the article is showing it's age. It's no longer true. 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.
  - causal 3mo ago
    I think it was always hyperbolic to call rewrites the single greatest mistake (I can think of worse) but I think most of the wisdom still holds. And AI generated rewrites are arguably riskier because now NOBODY is familiar with the massive codebase.
  - RetroTechie 3mo ago
    > It's funny, but I think the article is showing it's age. It's no longer true. 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).
    - Ygg2 3mo ago
      > Developer & time-cost of a rewrite is a big unknown... An optimist might say this cost has vanished. 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.
CrimsonRain 3mo ago
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?
hinkley 3mo ago
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.
- nz 3mo ago
  Owners and developers. I've been thinking about this a lot lately. Years ago, maybe in the late 2000s, when startups were becoming culturally significant, and "Tech" became an "Industry", two books were written and published: Founders at Work by Livingston, and Coders at Work by Seibel. I read both, and recall the Founders-book being a bit of a slog -- I only read it once[0]. The Coders-book, I have been re-reading it for more than a decade. I am sure there are many people who would express the _opposite_ sentiment. 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 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).
vga1 3mo ago
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.
- andsoitis 3mo ago
  > There's gonna be amazing products made with LLM You think more amazing than what was made without LLM?
  - vga1 3mo ago
    There is going to be something that would not have existed without LLM because there wouldn't have been enough resources to create it before. Probably already is. Some of it will be amazing, although most of it probably not. Example: Qobuz has no official Linux client, but there's https://qbz.lol/ 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.
    - andsoitis 3mo ago
      I hear you, and those are good applications of LLMs: create something that didn't make economic sense before. 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.
      - vga1 3mo ago
        I think it's possible, but probably beyond my capability of imagination, so I cannot give a satisfying answer beyond this.
jgalt212 3mo ago
> 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.
simjnd 3mo ago
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?
- busterarm 3mo ago
  Context matters. Big announcements and uninformed blog posts can kill your momentum. 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…
  - deleted 3mo ago
    [deleted]
  - diegoholiveira 3mo ago
    I remember that. It was the first time I heard about Scala. 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.
    - busterarm 3mo ago
      It didn't even end there at Twitter. 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.
  - JetSetIlly 3mo ago
    Similar to Discord's migration from Go to Rust. The measurements and reasons they gave were true but even by the time of the migration, Go had already moved on and improved. They were using an old version of Go. 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.
torginus 3mo ago
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.
- woodruffw 3mo ago
  I think their original post lays out the benefits pretty well. I think the realization of some of these benefits is debatable (for example, they probably could have made their existing Zig code faster), but others are straightforward (like having fewer crashes because more of your code is provably “safe” in Rust terms). (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.)
- lolinder 3mo ago
  > making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust. 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.
- lyu07282 3mo ago
  They listed some of the memory bugs they had in the blog post, I just looked at three of them, the first one was this: > 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/issues/121 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/621c4016218bb782e05907757c47bd5fa1961242 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/issues/121 https://github.com/spaceraccoon/vulnerability-spoiler-alert/... https://github.com/nodejs/node/commit/53bcd114b10021c4a883b08df4d3c2ff6946b430 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/8f1a9540fdff25410506de76e0da2506d260c08f/src/runtime/node/node_zlib_binding.rs#L715 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/79522ab6c579736dc239fa8521ca0f124cdf84e0 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/912970c98437e418a95b6b5b77f91e3b16134598 https://github.com/oven-sh/bun/commit/912970c98437e418a95b6b... Code side-by-side: Rust: https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76e0da2506d260c08f/src/css/properties/background.rs#L693 https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76... Zig: https://github.com/oven-sh/bun/blob/912970c98437e418a95b6b5b77f91e3b16134598/src/css/properties/background.zig#L656C16-L656C31 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}; Which is a bit concerning?
criley2 3mo ago
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).
mooreds 3mo ago
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:7482123212504330241/ https://www.linkedin.com/feed/update/urn:li:activity:7482123... 1: https://www.honeycomb.io/blog/disposable-code-is-here-to-stay https://www.honeycomb.io/blog/disposable-code-is-here-to-sta...
cavoirom 3mo ago
I guess the Rust rewrite is the exit path of the Bun's author so that the others could "handle" the code base.
pier25 3mo ago
> 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_to_use_the_rust_port_of_bun/ https://www.reddit.com/r/bun/comments/1u3j4d7/are_you_going_...
piokoch 3mo ago
"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.
cactusplant7374 3mo ago
> 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.
deaton 3mo ago
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.
- lolinder 3mo ago
  If the end state were unsafe Rust, you'd be right, but that's explicitly not the intended end state. Unsafe Rust was the reachable first step. Now they have a Rust version and can iteratively remove `unsafe`, which they couldn't do before when it was in Zig.
  - selfmodruntime 3mo ago
    It's the wrong abstraction though and I am kind of not surprised the Bun maintainers went way. The correct abstraction would be to translate into Rust while using `clone` and `copy` liberally and then iteratively converting to a borrowing model. Nowhere at all was an introduction of the `unsafe` keyword needed.
    - lolinder 3mo ago
      That's only the correct abstraction if you intended to hold off on releasing the rewrite until you were completely finished, because there's no universe where Bun of all projects releases a production version that uses clone and copy liberally. 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.
      - metoobruh 3mo ago
        [flagged]
Lerc 3mo ago
>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?
FeepingCreature 3mo ago
> 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.
saghm 3mo ago
> 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.
causal 3mo ago
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.
UltraSane 3mo ago
This is why IBM still sells so much ancient z/OS mainframe code, things like CICS are the most tested code in existence.
- pjmlp 3mo ago
  And you can even program for z/OS and Aix with Go and Rust. https://www.ibm.com/products/open-enterprise-sdk-go-zos https://www.ibm.com/products/open-enterprise-sdk-go-zos https://www.ibm.com/products/open-sdk-for-rust-aix 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.
hoppp 3mo ago
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?
selfmodruntime 3mo ago
> 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.
sporkland 3mo ago
> 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.
- twister2920 3mo ago
  > They believe they themselves will be out of jobs at that point. now THAT is cynical
- afavour 3mo ago
  > I know a few people at anthropic and oai > 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.
- nsagent 3mo ago
  Then they are naive. I've seen this a lot first hand during my PhD. Interpreting results in a way that reinforces their beliefs and ignores alternate hypotheses. 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. [1]: https://arxiv.org/abs/2304.15004 https://arxiv.org/abs/2304.15004
  - 27183 3mo ago
    The number of people who think the emergence thing is settled smh... It's been a thing for at least 30yr, answering it one way or the other would be a big deal. It does nobody any favors having these infinitely capitalized hype firms calling themselves "labs".
chuckadams 3mo ago
> 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).
- ivanjermakov 3mo ago
  According to Andrew, bun-zig is not something some brave soul would be eager to maintain. > 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.
  - chuckadams 3mo ago
    How many lines of code is Node, which is a wrapper for v8? I'm aware bun is not great quality, I tried and abandoned it myself, but Andrew's consistently bitter and spiteful tone makes him the worst conveyor of his own message.
    - ivanjermakov 3mo ago
      > How many lines of code is Node src/ 143k lib/ 127k test/ 716k deps/v8/ 3.6M
stellamariesays 3mo ago
[flagged]
TacticalCoder 3mo ago
> 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".
redwood 3mo ago
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.
pizlonator 3mo ago
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.)
joshgachnang 3mo ago
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.
ksec 3mo ago
>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.
- J_Shelby_J 3mo ago
  Agreed. That seemed to be the consensus in /r/rust
zem 3mo ago
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.
overgard 3mo ago
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.
getpokedagain 3mo ago
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.
arjie 3mo ago
> 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.
naasking 3mo ago
> 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.
waterTanuki 3mo ago
> 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?

herrkanin 3mo ago

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

cyber_kinetist 3mo ago
> clear well-scoped unsafe boundaries 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!)
- baokaola 3mo ago
  There's only one language that's more dangerous than C and that is unsafe Rust. I say that only half-jokingly.
  - Ygg2 3mo ago
    Good job falling for the Zig propaganda. I say that half-jokingly. EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.
    - selfmodruntime 3mo ago
      This isn't propaganda, the Rust compiler's rules when using the unsafe keyword are difficult to uphold, which is why the community wrote Miri.
      - Ygg2 3mo ago
        Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? And how does Miri help solve this issue?
        selfmodruntime 3mo ago
        > Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? By the engineer's wit of course! > And how does Miri help solve this issue? By detecting undefined behavior caused by violation these rules
        dwattttt 3mo ago
        Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.
        Ygg2 3mo ago
        > By the engineer's wit of course! 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?
- lolinder 3mo ago
  No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said: > 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.
  - cyber_kinetist 3mo ago
    > We can gradually refactor it 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.
    - Tadpole9181 3mo ago
      You're not helping your case. 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.
      - metoobruh 3mo ago
        You're not helping your case. > [what you just wrote] So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.
        Tadpole9181 3mo ago
        Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine. Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
- selfmodruntime 3mo ago
  There is almost zero reason for a public facing, non-embedded project like Bun to use unsafe anywhere.
  - cyber_kinetist 3mo ago
    You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)
petesergeant 3mo ago
I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.
lunar_mycroft 3mo ago
Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.
- selfmodruntime 3mo ago
  This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.
  - lunar_mycroft 3mo ago
    You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
    - Tadpole9181 3mo ago
      Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?
      - lunar_mycroft 3mo ago
        > Which is still a step ahead of Zig 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.

lennxa 3mo ago

the rust is merged into main https://github.com/oven-sh/bun https://github.com/oven-sh/bun and the rust version has been live in claude code since june 17th.

sph 3mo ago

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.

manphone 3mo ago
It’s the same reason why everyone doesn’t wanna read LLM generated blog posts. The agreement used to be generally that you would spend more time writing than I would have to spend reading and when the agreement changes the quality changes as well.
- pydry 3mo ago
  Or rather because they are always just of poor quality
  - pmarreck 3mo ago
    Define “quality” (I’m pretty sure both you and I would “know it when we see it”, but…)
    - lproven 3mo ago
      There was an entire book about that 50 years ago, and last month someone brought that thinking and analysis to the LLM-bot issue: EDIT: this is the one I was thinking of... https://sinclairtarget.com/blog/2026/06/01/quality-in-the-age-of-slop/ 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-generative-ai https://bersas.substack.com/p/zen-and-the-dance-of-generativ...

petcat 3mo ago

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

ACCount37 3mo ago
I used to think there's a good niche for "better C" - and that Zig was the one language angling for that. A language that can be used in the same contexts as C, to do the same things as C code, in very much the same way, but with some modern features, some stronger guarantees and some helpful syntactic sugar? A welcome thing for embedded development. 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.
- ctvo 3mo ago
  I wouldn’t write Zig off yet. The faster compilation time is a giant moat. Depending on how LLM usage evolves it could be what ends up mattering.
  - pmarreck 3mo ago

hypfer 3mo ago

> 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-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Ygg2 3mo ago
It's funny, but I think the article is showing it's age. It's no longer true. 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.
- causal 3mo ago
  I think it was always hyperbolic to call rewrites the single greatest mistake (I can think of worse) but I think most of the wisdom still holds. And AI generated rewrites are arguably riskier because now NOBODY is familiar with the massive codebase.
- RetroTechie 3mo ago
  > It's funny, but I think the article is showing it's age. It's no longer true. 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).
  - Ygg2 3mo ago
    > Developer & time-cost of a rewrite is a big unknown... An optimist might say this cost has vanished. 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.

CrimsonRain 3mo ago

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?

hinkley 3mo ago

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.

nz 3mo ago
Owners and developers. I've been thinking about this a lot lately. Years ago, maybe in the late 2000s, when startups were becoming culturally significant, and "Tech" became an "Industry", two books were written and published: Founders at Work by Livingston, and Coders at Work by Seibel. I read both, and recall the Founders-book being a bit of a slog -- I only read it once[0]. The Coders-book, I have been re-reading it for more than a decade. I am sure there are many people who would express the _opposite_ sentiment. 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 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).

vga1 3mo ago

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.

andsoitis 3mo ago
> There's gonna be amazing products made with LLM You think more amazing than what was made without LLM?
- vga1 3mo ago
  There is going to be something that would not have existed without LLM because there wouldn't have been enough resources to create it before. Probably already is. Some of it will be amazing, although most of it probably not. Example: Qobuz has no official Linux client, but there's https://qbz.lol/ 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.
  - andsoitis 3mo ago
    I hear you, and those are good applications of LLMs: create something that didn't make economic sense before. 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.
    - vga1 3mo ago
      I think it's possible, but probably beyond my capability of imagination, so I cannot give a satisfying answer beyond this.

jgalt212 3mo ago

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

simjnd 3mo ago

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?

busterarm 3mo ago
Context matters. Big announcements and uninformed blog posts can kill your momentum. 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…
- deleted 3mo ago
  [deleted]
- diegoholiveira 3mo ago
  I remember that. It was the first time I heard about Scala. 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.
  - busterarm 3mo ago
    It didn't even end there at Twitter. 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.
- JetSetIlly 3mo ago
  Similar to Discord's migration from Go to Rust. The measurements and reasons they gave were true but even by the time of the migration, Go had already moved on and improved. They were using an old version of Go. 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.

torginus 3mo ago

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.

woodruffw 3mo ago
I think their original post lays out the benefits pretty well. I think the realization of some of these benefits is debatable (for example, they probably could have made their existing Zig code faster), but others are straightforward (like having fewer crashes because more of your code is provably “safe” in Rust terms). (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.)
lolinder 3mo ago
> making sure the JIT doesn't emit anything broken or naughty is completely outside the scope of Rust. 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.
lyu07282 3mo ago
They listed some of the memory bugs they had in the blog post, I just looked at three of them, the first one was this: > 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/issues/121 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/621c4016218bb782e05907757c47bd5fa1961242 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/issues/121 https://github.com/spaceraccoon/vulnerability-spoiler-alert/... https://github.com/nodejs/node/commit/53bcd114b10021c4a883b08df4d3c2ff6946b430 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/8f1a9540fdff25410506de76e0da2506d260c08f/src/runtime/node/node_zlib_binding.rs#L715 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/79522ab6c579736dc239fa8521ca0f124cdf84e0 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/912970c98437e418a95b6b5b77f91e3b16134598 https://github.com/oven-sh/bun/commit/912970c98437e418a95b6b... Code side-by-side: Rust: https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76e0da2506d260c08f/src/css/properties/background.rs#L693 https://github.com/oven-sh/bun/blob/8f1a9540fdff25410506de76... Zig: https://github.com/oven-sh/bun/blob/912970c98437e418a95b6b5b77f91e3b16134598/src/css/properties/background.zig#L656C16-L656C31 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}; Which is a bit concerning?

criley2 3mo ago

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

mooreds 3mo ago

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:7482123212504330241/ https://www.linkedin.com/feed/update/urn:li:activity:7482123... 1: https://www.honeycomb.io/blog/disposable-code-is-here-to-stay https://www.honeycomb.io/blog/disposable-code-is-here-to-sta...

cavoirom 3mo ago

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

pier25 3mo ago

> 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_to_use_the_rust_port_of_bun/ https://www.reddit.com/r/bun/comments/1u3j4d7/are_you_going_...

piokoch 3mo ago

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

cactusplant7374 3mo ago

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

deaton 3mo ago

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.

lolinder 3mo ago
If the end state were unsafe Rust, you'd be right, but that's explicitly not the intended end state. Unsafe Rust was the reachable first step. Now they have a Rust version and can iteratively remove `unsafe`, which they couldn't do before when it was in Zig.
- selfmodruntime 3mo ago
  It's the wrong abstraction though and I am kind of not surprised the Bun maintainers went way. The correct abstraction would be to translate into Rust while using `clone` and `copy` liberally and then iteratively converting to a borrowing model. Nowhere at all was an introduction of the `unsafe` keyword needed.
  - lolinder 3mo ago
    That's only the correct abstraction if you intended to hold off on releasing the rewrite until you were completely finished, because there's no universe where Bun of all projects releases a production version that uses clone and copy liberally. 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.
    - metoobruh 3mo ago
      [flagged]

Lerc 3mo ago

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

FeepingCreature 3mo ago

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

saghm 3mo ago

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

causal 3mo ago

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.

UltraSane 3mo ago

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

pjmlp 3mo ago
And you can even program for z/OS and Aix with Go and Rust. https://www.ibm.com/products/open-enterprise-sdk-go-zos https://www.ibm.com/products/open-enterprise-sdk-go-zos https://www.ibm.com/products/open-sdk-for-rust-aix 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.

hoppp 3mo ago

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?

selfmodruntime 3mo ago

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

sporkland 3mo ago

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

twister2920 3mo ago
> They believe they themselves will be out of jobs at that point. now THAT is cynical
afavour 3mo ago
> I know a few people at anthropic and oai > 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.
nsagent 3mo ago
Then they are naive. I've seen this a lot first hand during my PhD. Interpreting results in a way that reinforces their beliefs and ignores alternate hypotheses. 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. [1]: https://arxiv.org/abs/2304.15004 https://arxiv.org/abs/2304.15004
- 27183 3mo ago
  The number of people who think the emergence thing is settled smh... It's been a thing for at least 30yr, answering it one way or the other would be a big deal. It does nobody any favors having these infinitely capitalized hype firms calling themselves "labs".

chuckadams 3mo ago

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

ivanjermakov 3mo ago
According to Andrew, bun-zig is not something some brave soul would be eager to maintain. > 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.
- chuckadams 3mo ago
  How many lines of code is Node, which is a wrapper for v8? I'm aware bun is not great quality, I tried and abandoned it myself, but Andrew's consistently bitter and spiteful tone makes him the worst conveyor of his own message.
  - ivanjermakov 3mo ago
    > How many lines of code is Node src/ 143k lib/ 127k test/ 716k deps/v8/ 3.6M

stellamariesays 3mo ago

[flagged]

TacticalCoder 3mo ago

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

redwood 3mo ago

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.

pizlonator 3mo ago

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

joshgachnang 3mo ago

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.

ksec 3mo ago

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

J_Shelby_J 3mo ago
Agreed. That seemed to be the consensus in /r/rust

zem 3mo ago

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.

overgard 3mo ago

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.

getpokedagain 3mo ago

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.

arjie 3mo ago

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

naasking 3mo ago

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

waterTanuki 3mo ago

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