5 ms·

I understand their decision. How could the maintainers understand their codebase if most of it was not directly written by them? It is impossible to review the

• thatxliner 5mo ago
  it's funny how the readme still says "written in Zig"
  • prmoustache 5mo ago
    If Claude isn't even able to correct the readme, I don't know how one can have hope it produces decent results.
  • sinpif 5mo ago
    Maybe it should say "designed in Zig" because most of the work & thinking was done using that language. The rewrite has no such history.
    • xeonmc 5mo ago
      Is that the new "Designed by Apple in California" equivalent of "Made in China" euphemism but for vibecodes?
      • sinpif 5mo ago
        More like "Designed by Apple in California, then copied as a cheap knockoff, never to be touched by a serious designer again".
• trollbridge 5mo ago
  Right. I now have responsibility for rather large codebases where the person who generated it with agentic tools (I'd say it's better than pure 'vibe coding') barely understands how it works. This is okay for unimportant parts of the codebase, but completely unacceptable for a critical piece of infrastructure where it really needs to be well thought out.
  • otabdeveloper4 5mo ago
    > This is okay for unimportant parts of the codebase Not really. At some point the technical debt accumulates and the only option is to trash it all and start over. The only party that profits here are the cloud token providers.
• sroussey 5mo ago
  I don’t think changing from zig to rust suddenly means that don’t know what a certain file contains or how it works or how it relates to other files. It’s all the same just different syntax. Which, by the way, is why it looks ugly to rust developers. The devs wanted the code to look familiar to them. I do think they should have called this 2.0 though. Would not feel such a rush (1.3.14 has a few regressions, and no one really cares because there are lots of small rust fires now). Overall, the bigger issue is that bun chases shiny objects. But never finishes. Just look at test stuff. Most of vistest, but not all. Most of jest, but not all. Most of pnpm, but not all. Now we have image stuff, so most of sharp, but not all. dev server? Most of vite, but you guessed it… not all. Long running process… mostly like node but with memory leaks (and a motivation for rust I’m sure). When I saw them posting about the Image routines my heart sank. Another shiny object. Coincided with test bugs so I moved to vitest completely.
  • egorfine 5mo ago
    > Image routines my heart sank. Another shiny object With quite a peculiar set of supported formats different between operating systems.
  • ChoGGi 5mo ago
    I assume most of the complaints about the massive rewrite are in regards to AI, not Rust. As lots of large and small companies have shown, test suites can only find what you test for. Vibe coded test suites can find?
    • josephg 5mo ago
      On the whole, I think vibe coded test suites can be pretty good. But it really depends on how you prompt. I often get the AI to brainstorm needed tests into a text file while it works. Then later I get another agent to write tests based on the list. It does a reasonable job. Its also pretty good at writing regression tests when it fixes a bug. Where LLMs struggle - or at least where claude struggles - is fixing the actual bugs. Its very good at getting the test suite to pass. But it cheats. It'll sometimes disable a test, or do some hacky workaround that makes the test pass that doesn't fix the underlying issue. It'll say "All done, the tests pass". But sometimes you really wish they didn't. I'm wondering if it might be better to set up 2 agents adversarially for bug hunting. Give one agent the goal of finding as many bugs as possible (via tests and other techniques). And another agent has the goal of fixing the bugs.
• nkmnz 5mo ago
  So it was possible to write ~2 million lines of (mostly) zig, but it's not possible to review ~1 million lines of rust, even though the same test suite included in those 2 million lines of zig can still be used? I'm not convinced the rewrite is a good idea and will work out, but I'm equally unconvinced by your argument.
  • 827a 5mo ago
    Its possible to do that over a period of a few years. Sadly, the Rust rewrite happened in (checks notes) 8 days.
    • doug_durham 5mo ago
      [flagged]
    • cyanydeez 5mo ago
      So this question was never answered: If Zig had so may problems that they felt compelled to rewrite it all in Rust, does that suggest the great Mythos was unable to fix the Zig version? Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version? Really? Did they just completely admit that the great AI future can't secure a significant project repository?
      • Jblx2 5mo ago
        https://duckduckgo.com/?ia=web&q=bun+fork+of+zig+compiler https://duckduckgo.com/?ia=web&q=bun+fork+of+zig+compiler
      • 827a 5mo ago
        AI is extremely good at rewriting existing code, and rewriting code is a classic engineering productivity trap. That's a tale as old as time; "we need to rewrite the api in Go" said every new midlevel engineering hire ever. Of course, 9 times out of 10 we don't do it, because the unpredictable costs always outweigh the benefit, and in Jarred's case we're starting to see these costs surface. They aren't technical, they're political; broad swaths of the community have lost faith in him and the Bun project.
• hexage1814 5mo ago
  [flagged]
  • overgard 5mo ago
    [dead]
  • grebc 5mo ago
    THIS time it’s different.
  • tomjakubowski 5mo ago
    > in many aspects of human history, we have traded understanding for convenience—that's the reason why we buy food at the supermarket instead of hunting for our meal. You could always take a job on a cattle ranch or an abattoir or meat-packing plant, or watch a How It's Made documentary, and get some understanding of how the sausage gets made and put on the supermarket shelf for your convenience. This was also true as we built abstractions in computer technology: you could start off learning a high level language, then learn a lower level one, then study or build an operating system kernel, a compiler, an assembler, machine code, and then crack some books on microprocessor architecture and signal processing. You could always "go deeper" if you wanted to. And there is a payoff: understanding at a deeper level helps you get things done better at the higher levels (e.g.: understanding the concept of memory hierarchy helps you lay out data structures to make code faster). There is no such step for slop-coded codebases: you become entirely dependent on a context-limited LLM to have a shot at even approximating some understanding. The proponents of this style will tell you, don't look at the code. It's the antithesis of every other abstraction we've built in computing. Perhaps more productively, you treat the slop as a black box and build something understandable around it. This is also why the notion that developers in the future will be committing LLM prompts in English to repositories instead of code written in a programming language is so foolish. I am saying this as someone who uses LLMs quite a lot to help with generating and understanding code.
    • solenoid0937 5mo ago
      The limitations are far overstated. Who cares if you don't understand every bit but the LLM does? Is the LLM good enough to ship to prod? Great. Understanding every corner of your codebase is overrated. LLMs, properly harnessed, are good enough.
• doug_durham 5mo ago
  I'm certain that the maintainers of Bun have excellent understanding of their codebase. What makes you think that they don't? They wrote the code in the first place. They know the architecture. They know what pieces do what functions.
  • somebehemoth 5mo ago
    They did not write the rust code. AI wrote that code. Your response is side stepping the primary issue people have with the rewrite: no human has read and understood all the code AI wrote.
    • tomjakubowski 5mo ago
      I agree but would propose the weaker argument: no set of human contributors have, put together, read and understood all the code. Even in artisanal-coded projects of sufficient size, it's rare that any one human has read and understood all of it.
      • ChoGGi 5mo ago
        The million or so lines of the original code has been "battle tested" for what it's worth. This is a massive codebase created within a week or so ago, no one can say what it will do till it does.
      • altmanaltman 5mo ago
        "No human understands any of the code" is not the same as "no human understands the entirety of codebase fully". Very different situations.
    • IshKebab 5mo ago
      I had an actual look at the code, and because it's a translation it's not just straight up de novo slop. The bits I saw were fairly straightforward 1:1 translations, so the Bun developers should still be familiar with the overall structure and logic. I still think it's mad, but not quite as mad as you might first think from the headlines.
• eddythompson80 5mo ago
  Pretty normal in many corporate cultures especially ones with high turnover. You get assigned to a team that's "maintaining" a 10 year old code base with few million LoC. The most senior person on the team has been there for a year or 2 and it's just business as usual. You don't know what those 1M+ lines are doing. No one does. It's not a passion of anyone to work on it. You just get a bunch of requirements handed to you, you blackbox everything but the surface areas you need to touch. It's why there are 14 implementations of a background service 8 dependencies that do the same thing, 6 overlapping frameworks, a complete mismatch in style, approaches, etc. It doesn't really matter.
  • egorfine 5mo ago
    Human-written code is theoretically surmountable. Large LLM-written code is called slop for a reason. It's hard to understand because oftentimes it does not follow human logic.
    • elzbardico 5mo ago
      Even a bad developer, that is, the average developer, develops a whole in which the parts have some degree of coherence. AIs simulate that, but they don’t have intent and thus this coherence is broken in large code bases.
  • gryn 5mo ago
    > It doesn't really matter. It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or expensive machines and they can't just buy another one for another X years.
    • eddythompson80 5mo ago
      yes, of course. I meant "it doesn't really matter" in the sense that businesses have been dealing with this since the beginning of software. Strong ownership and passion was one of the selling points of OSS, but that style of ownership was always very very rare in corporate. It just doesn't really fit with how businesses operate. The "passion" is ARR, not engineering principals. Most software is built, sold, and bought by people who don't use it directly.
• giancarlostoro 5mo ago
  I'm very skeptic that they read the entire codebase of Bun prior.
  • solenoid0937 5mo ago
    yeah this just feels like an attention stunt tbh
  • lelanthran 5mo ago
    > I'm very skeptic that they read the entire codebase of Bun prior. Well, they didn't really need to. A complete rewrite is effectively a different project. You may feel comfortable using a new project in prod, but most people are not. Project A: used in production for 3 years - high trust. Project B: Has yet to be used in production - low trust. IDGAF about automated tests, let other users shake out the inevitable bugs that show up in prod and after a few years of stability, then we'll see. To me, it's not about whether humans reviewed the code or not (they didn't), it's more about "here's this brand-new shiny codebase of ~1m Sloc, of which exactly zero lines has been used in prod".
    • skydhash 5mo ago
      People that like AI are always happy to point out that their code was written fast and passes tests. For me thats just the bare requirement to have more than a “wip” commit on my local codebase. To create a PR, I need to test it manually. But the only true test is to survive production usage for a while. That’s where edge cases become normal occurrences.
• TheCoreh 5mo ago
  It's not impossible, or even that hard to review the entire rewritten codebase. 10 engineers each reviewing 5,000 LoC a day for 20 days can do it. And that is being highly conservative with the estimate. A good chunk of the the code is probably highly trivial boilerplate one can easily skim over in minutes.
  • paxcoder 5mo ago
    [dead]
  • backwardsponcho 5mo ago
    And five engineers reviewing 20 thousand LoCs would get the job done in ten days, but both numbers are just as BS when it comes to actually understanding the codebase. No one is comprehensively reading 5k lines per day for a month straight.
    • roblh 5mo ago
      Seriously, “just review 5k lines a day for a month” is the most out of touch manager suggestion I’ve seen in a hot minute. As though you only need to read each line one single time in a review before magically committing its exact purpose, content, and overall implications to memory. The absurdity of which is multiplied for AI generated code which, based on what I see from my coworkers, is clunkier and weirder and less focused even than regular human code, on average.
      • TheCoreh 4mo ago
        This is not a regular code review of new code. The original code still exists, and is sitting side by side, just in a different language. You'd be just looking at both files, side by side, to make sure nothing was lost in translation or newly introduced.
  • bentcorner 5mo ago
    20 days is rookie numbers. I can get a million engineers to each review a single line and finish code reviewing the entire code base in a minute.
• crowcroft 5mo ago
  This is why I require all my software to have bespoke compilers otherwise how can I trust the devs know what their code is actually running!?
  • manquer 5mo ago
    Just because we don't understand or know about compilers or able to read their output does not make them fungible. In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked. The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it worked, but nonetheless felt the differences and chose with dollars and usage .
    • crowcroft 5mo ago
      Part of what I’m getting at is exactly your point that we used to think about what compiler to use and didn’t always blindly trust them. If you have enough tests at what point does AI rewriting software in a different language become close enough to ‘deterministic’? Maybe never, maybe not.
      • LtWorf 5mo ago
        The AI will normally cheat and edit the tests.
• halyconWays 5mo ago
  >How could the maintainers understand their codebase if most of it was not directly written by them? Counterpoint: I look back at code I wrote a few years ago and just take it on faith that I knew what I was doing at some point. That's still better than never knowing, but it requires faith--faith in a human, vs. faith in an LLM.
  • coderenegade 5mo ago
    Yep. These days, simplicity is a massive part of my development style. I don't want to be looking at a codebase, even my own, and thinking "shit, this guy was way smarter than me".
• solidasparagus 5mo ago
  They support Windows, which is many millions of lines of code not written by the current maintainers.
  • phire 5mo ago
    It's a bit harder to avoid windows than it is to avoid Bun. More importantly, it's not the same thing at all. All the code in windows (at least until recently) was written by humans, understood by humans and reviewed by humans. And that code has stood the test of time, proven its value and stability in the wild, on billions of systems. The fact that the current maintainers haven't needed to understand or replace the code is some indication of the code's quality. Almost none of Bun's rust code has been even seen by a human, and it's only about two weeks old. I'm somewhat willing to accept vibe-coded code if it's either absolutely non-critical, well reviewed, or maybe in the long term if it's proven itself. But not two week old code.
    • solidasparagus 5mo ago
      That's a valid way to approach this - bun isn't valuable enough to bother with or at least wait for a while, Windows is. But I think the comparison is closer than you are making it sound. I sincerely doubt the Windows codebase was all written by humans, let alone reviewed. And my understanding is that the code is being regularly rewritten and replaced because of how flawed it is, it's just a massive undertaking. Also if you look at their investment in AI-driven code rewriting into Rust, my bet would be that some modern Windows code itself is being vibe-coded.
      • altmanaltman 5mo ago
        I mean should we even compare Bun to Windows in the first place? Like Mircosoft with its resources would find a way to support Bun and Windows is one of their most popular and most used products. The situation with Bun is very different in terms of business/product.
  • elzbardico 5mo ago
    Windows have a incredible degree of architectural coherence and design intentionality. It is far easier to understand some part of the various NT source code leaks than it is to understand Claude code leak
• vitally3643 5mo ago
  Completely regardless of how the code was written or even if anyone understands it thoroughly, they replaced the entire running codebase in a week. The entire project was one thing and is now something different. There are countless reasons that this is a very bad thing for consumers of Bun. First and foremost you've instantly lost any and all assurance that it works the way it's supposed to. Every project has load-bearing bugs that may or may not still exist. Can you trust the core behavior is the same? If the Bun maintainers are willing to completely replace their core product over the span of a week, how is anyone supposed to rely on it? What's preventing another rewrite in a few more weeks? If you want to position your product as a dependency, it needs to be stable and reliable. Throwing away a million lines of code and replacing the entire product overnight is pretty much the polar opposite of stable and reliable. It has nothing to do with AI rewriting the code, it's the reckless abandon and wild disregard for consumers that is the problem. It's literally a rug pull.
• Rexxar 5mo ago
  I don't use Node.js or Bun, so I'm little out of touch. But what need 1 millions lines of code as the js engine itself is a library ?
  • LtWorf 5mo ago
    I've been wondering the same.
  • simongr3dal 5mo ago
    THey need to provide all the API's that nodeJS provides. I'm sure nodejs has a lot of lines too even though they also have the js engine as a library.
• illiac786 5mo ago
  How much of the windows code has been written by its current maintainers? Little. I feel this argument is not valid, especially for large code bases. Documentation and code quality is what is important, not who wrote the code.
  • nozzlegear 5mo ago
    Isn't windows notoriously shoddy right now, so much so that Microsoft is making a big public effort to try to improve its quality?
    • illiac786 5mo ago
      True. But you can pick any code base with 20 years of existence, what I said applies.
  • ethin 5mo ago
    A project that's 2/5/10/30/100m LoC is obviously not going to be understandable entirely in someone's head. Documentation is critical. But if I'm reading your code, and I come across something confusing or you wrote something in a weird way and I want to understand, then I just... Come and ask you. "Hey, why did you do this this way? Did you consider x?" With an AI you can't do that. IMO this point is especially important if your code base is widely deployed to the point that people use it as a learning resource or a good source to learn good practices.