I have to say, this whole saga is extremely interesting. Not just from a popcorn-enjoyer's point of view, but as a bit of a bell weather for 2026 software dev.
Cpoll 1 days ago [-]
Trivia: The term is "bellwether," i.e. a wether (castrated sheep) wearing a bell, used to guide the flock.
consumer451 1 days ago [-]
I kept checking the thread for responses and finally realized it, but too late to edit. I will probably wake up in a few days from a nightmare about this misspelling on HN. Happens all the time, no joke.
I think that in my mind, it was always some sort of weather related bell, like you ring it, when the weather changes.
Hopefully the sheep reference will help me remember.
satvikpendem 16 hours ago [-]
You might be interested in https://hnreplies.com/ to automatically get an email for HN replies
eichin 21 hours ago [-]
I'd suggest reading the Connie Willis novel by that name - no idea if it will actually help, it's just really good writing :-)
Hnrobert42 18 hours ago [-]
I have ADHD. I am super sensitive to noise. When other people let their phones ding incessantly, it drives me crazy.
I went hiking in Albania recently. I saw many sheep grazing in the mountains. I wondered about the sheep chosen to wear the bell. Like, was it the same sheep every day? Did the chosen sheep think, "Fuck me this thing is annoying"?
giancarlostoro 1 days ago [-]
What's funnier to me is none of them seem to want to abandon npm which keeps getting exploited and hacked. NPM has been the source of just how many industry wide hacks? Three major ones, and a massive supply-chain industry wide campaign against npm. But yeah, bun is the real concern here.
I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.
zoogeny 23 hours ago [-]
Who do you mean when you say "none of them"?
At the least, my interpretation of deno lore is that they tried to ditch npm and found this limited their adoption so significantly that they had to patch it back in. That would provide sufficient warning to me that attempting to move away from npm was unwise.
> none of them seem to want to abandon npm which keeps getting exploited and hacked
Do you know of a better alternative for JS/TS that has all the popular packages?
rglover 24 hours ago [-]
Not perfect, but I use Verdaccio to run my own npm server and for third party deps, I clone, eval, and then if it's clean, push a safe copy to my own server (not for everything, just the most sensitive, hardcore stuff but eyeballing building a tool to semi-automate it due to recent chaos). You can even clone from remote URLs (point to a tarball from package.json instead of a version) so I've considered just using a private bucket.
Tedious, but makes the "npm hacked again" posts mostly moot.
Eufrat 23 hours ago [-]
I really think the actual problem is not the vibe coded aspect, nor questions about supply chain security. It is the apparently reckless and rushed nature of the rewrite which eroded user trust. In the span of about 2 weeks the narrative went from being an experimental branch to be being deployed as a canary ready for public testing. All the while the Jarred from Bun was posting here, promising blog posts and more transparency about what was going on. All that I can find is a single AI generated post (https://bun.com/bun-unsafe-audit) after people raised concerns about the quantity of unsafe calls in the Rust rewrite.
This is ridiculous and the response is entirely expected, it’s not about the code anymore, it’s about people. If you claim that doesn't matter, then I think the user response tells you otherwise. It signaled that Bun was not being transparent while asking people to trust it as a core runtime system. Why would I trust a runtime that actively would just do major changes so callously? There’s a balance between all of this. You don’t need to be as methodical as Python is now with PEPs. I think Swift got similar crap, though, nowhere as bad when it rolled out major language changes out of the blue to support Apple’s own product needs a few years back. This was kept secret and released in one burst, bypassing the entire Language Evolution process they crafted for Swift. Apple’s actions are more understandable by the nature of the company wanting to keep some things under wraps, even though it did erode trust somewhat. Apple is now a 50+ year old Fortune 100 company and Apple engineers really just kinda demurred on the bad taste it left in the community’s mouth, but at the same time, what do you expect from a company with a long history of being rather tight-lipped on major product changes. Bun has not really built this reputation nor has their parent company, but they are asking for that here and I just don’t think they have the leverage to do it.
They could have done this more methodically, made sure that the community and industry were okay with it. Maybe they actually did this more thoughtfully behind the scenes and this entirely a marketing stunt, but their lack of transparency at this moment makes it difficult to give them the benefit of the doubt. Trust is currently in short supply, burning it up on stunts like this is stupid.
buu700 21 hours ago [-]
Sounds about right. I think the response is a bit of an overreaction at this point, but an understandable and easily preventable one. It would have saved a lot of grief to have been more transparent and set clearer expectations: rather than yolo the experimental code into main, put it in a "v2" branch, publish an expected release timeline with 2.0.0 projected for ~Q4 2026 - Q1 2027, and announce a transition of 1.x to maintenance mode with only security fixes. The technical execution and release planning may or may not be excellent, but the political execution so far feels like an unforced error.
Eufrat 18 hours ago [-]
The other frustration is that the folks at Bun seem to entirely not get the problem they are creating for themselves.
One of the responses to this announcement was Jarred asking: “What issue did you run into with the Rust rewrite? If there’s something specific I’ll fix” Dude, this is a comms problem, not a technical problem. Refusing to accept that makes the situation worse and I think it is completely believable if Bun eventually dies over this because it’s clear the folks running the show don’t understand part of the process of winning customers is to build a community where Bun is just considered the obvious choice. I remember awhile back they also forked Zig to do some “optimization” that was pointed out by Zig maintainers to be worthless. There’s a pattern developing here and it’s not a good one.
fragmede 22 hours ago [-]
9 days just wasn't enough burn in. In an alternate reality, rust-bun ran in parallel for a least a month, if not three or six, before being merged.
Griffinsauce 14 hours ago [-]
Bun has always been about velocity over quality.
Their whole point was "drop in node replacement" - instead of hitting that target they built an entire framework of tools, seemingly changing focus every month or two, and are now rewriting all that to a new language.
yoav 7 hours ago [-]
Hi. Electrobun creator here.
I am building a new JS runtime called cottontail.
It’s just a prototype now but the goal is to have a huge standard library powered by native zig such that you don’t need npm.
So you’re right that npm is a disaster and I’m working on solving.
TiredOfLife 1 days ago [-]
Also Rubygems, Packagist, PyPi
ghusto 23 hours ago [-]
pip install pulls in what I've listed in my package list, plus their dependencies which are at most 2 levels deep. The dependency's dependencies are reviewable.
npm install pulls in my dependencies plus god knows what else at god knows how many levels. 500MB of dependencies? The dependency's dependecies are not reviewable.
I wish people would stop trying to compare NPM to PyPi and others. NPM is an unfixable disaster because of the entire mindset and ecosystem around JavaScript.
baggy_trough 1 days ago [-]
What's the worst hack to affect users of rubygems?
pwdisswordfishs 24 hours ago [-]
DHH, of course.
tankenmate 1 days ago [-]
From my perspective it is a synthesis of "It is difficult to get a man to understand something, when his salary depends upon his not understanding it." and "but npm is the source of all the shiny shiny!".
christophilus 1 days ago [-]
Time will tell. I predict this is just the same 20 year pattern of: people on the internet are irate about $latest_thing, and everyone will move on to some other hot topic.
jakobnissen 1 days ago [-]
But surely, whether or not the Internet mob moves on has no bearing on what actual lessons to learn from this saga. Will the vibe rewrite turn out to be a disaster or are LLMs already capable of writing human level code at this scale? That question is interesting no matter the level of attention this gets.
stephbook 1 days ago [-]
I'm believe projects that pin old versions or maintain their own shoddy fork will be left behind. Deprecation is fine.
versecafe 20 hours ago [-]
maintaining a fork on the zig version works short term but does open some questions about longterm stability/approach and if features should be cut to make maintenance easier; ie Bun.Image, fetch("", {grpc: true}), Bun.redis since it never got finished, etc
consumer451 1 days ago [-]
For some reason, when thinking about this, the visual of all the scientists at CERN camping out for the results of the Higgs Boson experiment jumped into my mind.
This is not as big an experiment as that. But, for software dev, it feels very significant.
Npovview 13 hours ago [-]
The same thing happened when MS acquired Github. So much outrage and so little action of moving to Gitlab.
1 days ago [-]
ifwinterco 12 hours ago [-]
Exactly, I'm glad bun has done this because it will be fascinating to see how it plays out.
I'm also glad I don't use bun
zoogeny 23 hours ago [-]
I think a more apt analogy (or cliche) is canary in the coalmine.
MuffinFlavored 1 days ago [-]
I wonder how many "behind the curve/not super modern" corporations were using Bun or Deno to begin with.
Part of me thinks it's a mild overreaction. It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux? As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded? Is it because it was an irresponsible thing to do? Maybe?
I don't know, I see both sides.
dahs12 1 days ago [-]
It isn't about users auditing Linux. The Bun developers don't audit "their own" (stolen) vibe code output. How would anyone know if it is secure?
atty 18 hours ago [-]
> as long as the tests pass
To be pedantic, tests prove that the code passes the test suite, nothing else. They do not prove by themselves that the code is correct, secure, maintainable, efficient, etc. Those are much harder to measure and have a ton to do with organization, architecture, culture, shared knowledge of the maintainers, etc. All of which is lacking during and after this rewrite.
nicoburns 22 hours ago [-]
> As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded?
Because the chances that they had a test suite that was actually comprehensive enough to guarantee correctness through this kind of refactor are approximately zero.
Normally we combine tests with careful "correctness by construction" design work and code review because we know that tests aren't sufficient.
worble 22 hours ago [-]
> It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux?
That's basically Torvolds full time job?
fallenscope 1 days ago [-]
[dead]
ibejoeb 1 days ago [-]
People are going to be using a lot less software if the selection criteria include not being no agents.
skeeter2020 1 days ago [-]
This is a very uncharitable interpretation of the twitter post: "It’s a combination of anthropic’s stance of not doing human reviews or any kind of rational roll out and stabilization."
They mention nothing about agents being used, rather focus on humans in the review cycle and some sort of gated roll-out process. Why we would bin these practices in the name of a faster release cycle is an important question & debate.
ibejoeb 1 days ago [-]
I kind of agree, but it goes both ways. Has Jarred said that there was no review? I know that he stated that rust bun passes tests. Now, I don't know the amount or quantity of coverage, but as a thought experiment, let's assume they are good. What does that count for?
riffraff 1 days ago [-]
I think most people believe it unlikely that one million line of codes can be reviewed in one week, and the fact that tests pass does not imply good code.
I have no idea whether the new or old code is/was good, just pointing out what seems like a plausible thought process for people who object to this rewrite.
zoogeny 23 hours ago [-]
I think it is interesting, using your framing, to consider why people may or may not believe that one million lines of code could be reviewed.
I mean, until very recently, the idea that one million lines of code could be written (rather than mechanically translated) in a month was unbelievable.
It is clearly the case that times have changed since the tools have been updated. So if we challenge one assumption, why not also challenge the other?
Bun presumably will have access to Mythos, which is purportedly reviewing million line code-bases (Mozilla, etc.) and uncovering real value for the devs of those projects.
I find it hard to deny extrapolating these trends to this Bun rewrite.
rrvsh 18 hours ago [-]
> I mean, until very recently, the idea that one million lines of code could be written (rather than mechanically translated) in a month was unbelievable.
It is still unbelievable, because it still has not happened in this case. The agent wrote it. Nobody thinks it's unbelievable that an LLM can generate a million lines of code in a month. You either do not understand what the detractors are saying or are arguing in bad faith
nicoburns 22 hours ago [-]
Perhaps it will happen, but I am yet to see good results from AI code review (it can be useful as an additional review, but not (yet) as the sole source of review).
19 hours ago [-]
1 days ago [-]
yoav 7 hours ago [-]
Yes he said multiple times including to me yesterday that humans won’t code review as a matter of practice going forward.
ibejoeb 5 hours ago [-]
Wow, that's wild. Is that just bun, or is that the general practice at anthropic now?
conartist6 1 days ago [-]
yes, because as we know from history without agents there is no internet or technology or anything
ibejoeb 1 days ago [-]
What do you mean?
I'm saying that AI is going to develop software from here on. I don't think you can expect that a human is going to review every line of code. Not that it's good, but that's just how it is. It's not so different from manufacturing. A human is not reviewing every weld. I see a lot of sloppy beads, but in a lot of cases, it's good enough.
conartist6 1 days ago [-]
I'm saying that's self-evidently ludicrous. Software is not like welding. Do you think Notch could have become rich and famous by welding? How about Bill Gates, famous as a really consistent welder?
tmp10423288442 1 days ago [-]
> A human is not reviewing every weld.
On civil engineering projects, I’m pretty sure a human reviews each weld. For mass-produced things, maybe not, although a company would not look good in a lawsuit if they had inadequate inspection procedures which allowed a fault causing injury or death to occur.
youre-wrong3 1 days ago [-]
> On civil engineering projects, I’m pretty sure a human reviews each weld.
Nope. It’s sampled.
geraneum 21 hours ago [-]
Yeah because they are not auto regressively generated!
bigstrat2003 1 days ago [-]
There's no way that AI develops software from now on. It isn't remotely good enough for that, nor has it really gotten better in the past few years. We're going to see a push to use AI, then a move away from it once the dreadful quality of AI slop becomes too obvious to ignore.
ibejoeb 22 hours ago [-]
It hasn't gotten better in the past few years? Come on...
conartist6 22 hours ago [-]
in some ways it remains exactly the same technology with the same critical weaknesses
dahs12 1 days ago [-]
There was enough software that powered the Internet before 2023. We don't need laundered slop from criminals.
> Electrobun aims to be a complete solution-in-a-box for building, updating, and shipping ultra fast, tiny, and cross-platform desktop applications written in Typescript. Under the hood it uses bun to execute the main process and to bundle webview typescript, and has native bindings written in Objc, C++, and several core parts written in zig.
qsera 1 days ago [-]
I think it makes sense to stay away from large code bases built using LLMs until it is proven that it is possible to also maintain such code bases using LLMs or using reasonable human effort.
Zakis1 1 days ago [-]
It's alarming how people instantly jump to conclusions that Bun is now "AI slop".
Bun has been almost entirely worked on by LLM's for ~6 months now, long before the Rust re-write (source: https://x.com/jarredsumner/status/2054525268296118363). It already has been proven that LLM's can maintain such codebases.
kikimora 1 days ago [-]
Bun never was great in terms of stability. It has been vibe coded for 6 month but code was reviewed by a person.
>It already has been proven that LLM's can maintain such codebases.
Proven is a strong word. In my experience AI fails miserably at anything beyond junior level tasks. We will see soon, once bun goes into production.
esperent 1 days ago [-]
> Bun never was great in terms of stability
It's very easy to throw shade like this on software if you've got a bugbear with it. I'm sure you can even come up with a bunch of these "stability" problems when challenged on it. I know I could, for basically any large piece of software that I've ever used.
But really, is bun worse in this regard than any other similarly ambitious open source software within it's first few years?
conartist6 1 days ago [-]
see that's fine with me if they want to take a year or two of human time and do the rewrite properly
this is a piece of software with no architecture, and whose owners have no regard or respect for architecture. I can virtually guarantee that on average every bug they fix will create one new bug, because that's what it's like to work on software with no intentional architecture
brabel 1 days ago [-]
What are you talking about?? Bun in Rust is a port, almost exactly the same code base on a different syntax. The architecture did not change at all. Amazing how people comment without even knowing what they are talking about.
thayne 1 days ago [-]
Zig and Rust are significantly different languages. If bun has a good architecture in zig (which I don't know if it does or not), that doesn't necessarily mean it had a good architecture for rust. A direct translation of zig code would probably result in pretty unusual rust code, and probably a lot more unsafe usage than if it had been originally written in rust.
adampunk 1 days ago [-]
I don’t really understand this objection. For every tool that I use, am I supposed to divine the best underlying language for it and then determine whether or not it is written in that language? Don’t I have better things to do?
kikimora 23 hours ago [-]
Because of borrow checker you would build data structures differently in Rust compared to Zig. Automated translation simply maps Zig constructs onto unsafe Rust code. I have no idea how feasible it is to go from totally unique way of using Rust to mimic Zig to idiomatic Rust.
adampunk 22 hours ago [-]
I understand that. That’s a specific example of an inaptness moving from one language to another. That’s not what I’m talking about.
I am asking if we are expected to understand this hypothetical condition about all possible tools that we use. Should I have to worry that something is written in Python when it should’ve been written in C? It just seems like that in order to have a big concern here, I had to be really invested in what language Bun used. I guess the whole matter makes more sense if people are REALLY mad about something else and the choice of language is supposed to serve as a more respectable thing to be mad about.
thayne 21 hours ago [-]
I'm not saying that bun shouldn't be written in rust. I'm saying that since it was originally written in zig, there were undoubtedly architecture and design decisions that were made that made sense in zig, but not so much in rust. When rewriting something in a different language, especially one significantly different than the original it is common to need to re-architect some things, and mechanically translating line by line from one language is probably going to result in some low quality code, even if the original was decent.
I think that using AI to translate bun from zig to rust might produce a good starting point. But it was done one file at a time, with minimal human review, and I'm skeptical that the result is quality maintainable code.
adampunk 21 hours ago [-]
I don't want to say that skepticism is unwarranted, but I'm not sure we apply this level of scrutiny with any kind of defensible evenness. I just can't think of a single open source project I use where I'm aware of their refactor cadence and practice. I'm just...not checking in on their feature branches and stuff, and I think most people aren't. I couldn't tell you if the uv maintainers work at 3AM while high on drugs or at 9:30 AM wearing FORTRAN blue ties.
I dunno. I think my sense here is that the bun maintainers did something shocking and dramatic using AI and people are shocked and dramatized. They're not WRONG to be so. But I don't know that the shock comes out of any generalized duty of care we have toward open source tooling. I think the uncomfortable point that bun has been releasing for 6 months with smaller AI code edits hasn't really been reckoned with. If we were actually this invested in what was happening, the migration would've begun months ago when it was clear they were using agents to ship code faster than they were willing to review.
fragmede 22 hours ago [-]
What is that tool in relation to the rest of your workshop though? If it's a simple hammer that you can swap out for $20 and you only use it once a month, who cares what kind of metal it's made out of, as long as it works. But if the $6,000 4-axis CNC machine that's at the heart of your machine shop and every minute of downtime on it costs you money, if it's starting to rust, no, you don't have better things to do than to look into what it's made of.
adampunk 22 hours ago [-]
Yeah what if the tool is a JavaScript runner released for free?
What is being expressed here about Bun is using the language of due diligence but doesn’t seem to adhere to any of the sensibilities. Should we all be auditing our toolchains to understand internal decisions that each toolmaker undertakes? Maybe! DO WE? Absolutely not. The level of scrutiny bun is getting is *unusual*. They just did an unusual and dramatic thing, so it’s not surprising. But I just don’t believe that bun is being deprecated due to normal engineering discipline that we are constantly carrying and applying everywhere. That’s…just hard to buy.
fragmede 9 hours ago [-]
We're all only human, so the deprecation happening is gonna have some biasing going on due to how people feel about AI, yeah. JavaScript runners is a whole ecosystem separate from, say, Python. If Python went and said that the next version of Python, we're using this new AI transpiled runtime that we baked for nine days, people would also freak out "due to normal engineering discipline that we are constantly carrying and applying everywhere." The real question then is just how far off from normal is it? Maybe you don't do audits that you think you should be doing, but eg moving from Python 3.10 to 3.12 can be as rigorous or as yolo as you want. And those versions are old, too. Other ecosystems are going to take their time as well. LLVM isn't going to switch over to something AI banged out in nine days. They're going to have a long dragged out period where they run things in parallel for a while until everyone feels okay about it. If they'd even do something like that.
soraminazuki 1 days ago [-]
Very amazing indeed. Here you are making bold assumptions about a huge pile of code not a single human being has ever read in any meaningful amount.
brabel 24 hours ago [-]
The only assumption you need to make is how the process went about, which was described by Jarred on a HN comment when the PR was first discussed: they had prompt that described exactly how things should be translated, for each "pattern" they were using in Zig, an appropriate equivalent was described in Rust. Zig and Rust are not that different, both are system languages and things can be done similarly in both languages, so architecture-wise I would think the exact same thing would work fine. I am not sure whether the LLM actually wrote a transpiler which just followed the rules, or if it did the job itself, since that information is not public yet, as far as I know, but my guess is that the LLM wrote a transpiler to do the job, then reviewed/fixed compilation issues, then fixed tests. And I'm pretty sure some human interaction was part of that as well.
soraminazuki 20 hours ago [-]
So now you've gone from making assumptions to making up wild stories territory. Well, the commit granularity isn't that of transpiler passes, and more importantly, it's completely irrelevant to how the majority of the code hasn't even been read by anyone.
kikimora 23 hours ago [-]
Nobody reviewed resulting code. Maybe all tests are empty and this is why they pass. Maybe tests were modified to pass because this is the only thing LLM could do to make them pass. Maybe it hallucinated something in the process. We have no idea.
> It already has been proven that LLM's can maintain such codebases.
Is it? Seems like bugs in Claude Code are getting out of hands. That project has a bit more lifetime.
sibeliuss 22 hours ago [-]
Is it that, or is it just that every software developer, enterprise, dev and non-dev alike has their eyes on Claude Code as the most popular software project ever? Software in general has tons of bugs. People need to understand scale here, and what this looks like in practice. They're doing an incredible job given the circumstances.
nicoburns 21 hours ago [-]
> Claude Code as the most popular software project ever
I don't think that's true? The likes of Chrome, Linux, curl, sqlite, etc, are much more widely used.
sibeliuss 21 hours ago [-]
I'm not being literal. Revolutionary technology arrives on the scene, is extremely visible, changes a whole industry and frankly creates an entirely new economy. All eyes on Anthropic.
They don't get enough credit for being right in the middle of a revolution, yet still managing to ship something that largely works incredibly well, because this thing is a workhorse.
rrvsh 18 hours ago [-]
They don't get enough credit? Anthropic is making an insane amount of money. More popular software projects have made exponentially less and have received even less media attention/fame/whatever metric you might use to define success.
fallenscope 1 days ago [-]
> It already has been proven that LLM's can maintain such codebases.
It hasn't. Those are two different scenarios. The first is individual PRs into an existing, majority human-authored and understood codebase where the PRs are initiated and merged by humans even if the code is AI generated. The second is AI rewriting AI written code that no human eye has seen. Bun took a conservative, transliteration file-by-file approach so they still understand the data structures and architecture so they will probably be okay though.
ramon156 1 days ago [-]
Worked on by LLMs is fine, but the rust pr proved no one is reviewing anymore. You cannot review 1M LOC in 5 days.
wiseowise 1 days ago [-]
> Bun has been almost entirely worked on by LLM's for ~6 months now
So what you’re saying is that this boycot is 6 months overdue?
skeledrew 1 days ago [-]
I think what they're is all is well as long as they aren't told that LLMs are doing most of the work. Being in the know is the issue here IMO as they would've continued using without a word otherwise.
lioeters 1 days ago [-]
It's alarming how people are willing to overlook the obvious in-your-face sloppiness of the Bun rewrite. A million lines of code in 9 days, pushed to main branch, forced on the existing userbase irresponsibly.
Nobody understands the code, nor will they be able to maintain it without AI service as an external dependency. Give me a break, I'm not running that monstrosity on my machine. Everyone running production software should move away from Bun purely as a technical decision.
j_bum 1 days ago [-]
Do you use Claude code on your machine? That seems mostly vibe coded
sleples 1 days ago [-]
1. I don't use Claude Code, no.
2. It's amazing that a CLI wrapper is as buggy as it is.
3. Nevertheless, it's useable, and maybe for a CLI that's enough. I don't want a JS runtime running production to be the same mess.
wiseowise 1 days ago [-]
Claude Code isn’t a runtime that I use to execute my code with.
brabel 1 days ago [-]
If you use it to write code for you, then it kind of is, indirectly.
dbalatero 24 hours ago [-]
That is quite the stretch you're making.
yen223 22 hours ago [-]
I run my code on Emacs as nature intended
skeeter2020 1 days ago [-]
that seems comparable to taking a dev-time dependency, while bun is a runtime dependency. THey need to be treated very differently.
j_bum 22 hours ago [-]
Fair point, wasn’t considering it from this angle.
Griffinsauce 14 hours ago [-]
6 months is plenty of time to keep ignoring serious tech debt. I don't think your conclusion follows at all from such a short time.
yoav 7 hours ago [-]
That explains the massive rise in segfaults since they got acquired.
It’s approaching being as buggy as claude code which I’ve had to stop using even though I have 6 months free of max because it just crashes and freezes all the time.
RiOuseR 1 days ago [-]
[dead]
lazzlazzlazz 21 hours ago [-]
Yeah, bizarre and sad. And, unsurprisingly, Hacker News seems sympathetic. They are getting very old.
contextcost 1 days ago [-]
I have an idea on how to tell if a codebase is rotting under AI Agent maintenance.
We can collect and analyze how the coding agent reads code during programming tasks, and see if the code access and token consumption are steadily increasing for similar development tasks. If the code readability doesn't degrade for the agent, the maintainability of the codebase should be fine.
sheeshkebab 1 days ago [-]
Mist of human written codebases are unusable for llm dev by that definition.
giancarlostoro 1 days ago [-]
Turns out that if they're unusable by LLMs they're likely unusable by human devs. If you follow sane clean coding principles (like not having godclasses) it turns out coding agents (and humans!) can understand and navigate your codebase, especially if you use recognizable patterns, even with very light documentation.
sheeshkebab 1 days ago [-]
One of these days you’ll learn about “enterprise” code
giancarlostoro 1 days ago [-]
I have seen good enterprise code and bad enterprise code. Clean Code suggests progressive rewriting of bad code.
When you touch a file you have an opportunity for code clean up, add unit tests to ensure your changes break nothing, and refine the code.
skeeter2020 1 days ago [-]
We judge long-term quality of human codebases (at least OS) by ongoing activity; for LLM codebases maybe a consistent or increasing level of activity is a bad smell?
Great, the author speaks out what everyone thinks but cannot say, either due to being invested in the hype or due to effectively having a gag order from their employers:
The bun rewrite was Anthropic's Vietnam and the open source community needs to react and and build resistance.
asdfsa32 1 days ago [-]
In many a brand name company now tokenmaxxing is the name of the game; CryptoBase, FacePaper, AntiqueOptics, tinyflacid, they all use AI usage metrics as part of their perf review these days.
kimos 3 hours ago [-]
Are these… real names? I can no longer tell if this is satire.
1 days ago [-]
mentalgear 1 days ago [-]
While I'm certainly sceptical of pure LLM (re)-written software, I would have to assume in the case of the cyberattack vector that Anthropic used their new Mythos model to adequately test against.
Maybe someone has more info of them mentioning that.
bastawhiz 24 hours ago [-]
> to adequately test against
How does one determine what "adequate" looks like for a million lines of code?
You can't fit a million lines of code in a 1M token context window unless every line of code is one token. So you're just sort of praying you spend enough time/money burning tokens to shake out all the stuff that's bad or wrong.
InsideOutSanta 1 days ago [-]
I wouldn't be surprised if the kinds of security issues LLMs tend to create are the exact types of security issues LLMs are bad ar detecting.
skeeter2020 1 days ago [-]
so they are defending the LLM-generated code using another one of their LLMs, against attacks from yet other LLMs? So regardless of the outcome and impact on us, they win?
yoav 7 hours ago [-]
They want us to believe Mythos was so bad it kept shipping segfaults for the last 6 months.
And also that it’s capable and trustworthy enough to rewrite the whole runtime in another language flawlessly such that no human needs to code review?
Idiocracy.
impulser_ 1 days ago [-]
Jarred said this had nothing to do with Mythos or Anthropic.
conartist6 1 days ago [-]
I have a very, very hard time believing that. Surely the acquisition left his wealth largely in the form of Anthropic stock, so his personal definition of success is "rep Anthropic so my stock goes up" and at that point he has succeeded.
Me, I still have to be competent to succeed. I don't just get to declare that because I used AI the effort was a success, and I have 0 desire to work with those kinds of people.
shimman 1 days ago [-]
The concept of a "useful fool" is apt here.
fathermarz 8 hours ago [-]
I’m confused, isn’t this rewrite still unreleased as of today? Surely people understand that a simple, “do an audit for memory safety” will bring it up to par.
bobajeff 1 days ago [-]
This is my first time hearing about Electrobun it sounds like it could be a good alternative to electron. Their site mention CEF bundling as an option has anyone tried this?
torginus 8 hours ago [-]
Personally I am confused by this whole rewrite - the 'crown jewel' of Bun is Webkit, which is written in C++, which is 'unsafe'.
This seems like Tauri 2.0 - wrap something in Rust and claim the memory safety issues are gone.
nsonha 8 hours ago [-]
The author was pretty clear about his motivation on the language. It's to make it more sustainable for them to maintain bun (instead of directly making bun safer), but the former can and often will result in the latter.
Squarex 1 days ago [-]
They should probably change the name then.
avinassh 1 days ago [-]
TIL electrobun. How does it compare against electron?
wartywhoa23 1 days ago [-]
The diff is +bu.
yoav 7 hours ago [-]
Better in every way
ksec 1 days ago [-]
At this point I am wondering if anyone will be forking the Zig Bun to something else.
throwatdem12311 1 days ago [-]
It’s really only a matter of time until someone forks the Zig version of Bun.
What a slap in the face to all the Zig developers that spent their time, effort and probably even some money contributing to it.
jdw64 1 days ago [-]
Realistically speaking, when Anthropic acquired Bun, they naturally would have needed a narrative showcasing that their AI excels even at relatively new languages like Zig. But since the Zig camp explicitly declared an anti-AI stance, it makes perfect sense why things played out this way. It's a understandable business realit
asdfsa32 1 days ago [-]
Add todo item: learn zig.
1 days ago [-]
u_fucking_dork 1 days ago [-]
[flagged]
postepowanieadm 9 hours ago [-]
It's not about which programming language they use.
pessimizer 1 days ago [-]
To upper-middle class people, their job is a religion. Investing in a programming language is a decision to gamble thousands of hours of your life for a programmer. At some point of projects shifting away from your language, your mortgage and your children's tuition will be affected.
RadiozRadioz 13 hours ago [-]
I think it's a miscategorisation that programmers are upper-middle class. Lots would probably reach middle, but upper-middle is more tied to generational wealth and other factors of social prestige that aren't typically attainable for a normal working programmer.
Edit: You mentioned tuition, so you must be American. I am British and our social class "system" is different. I'll leave my comment as some may find it interesting.
newtonianrules 1 days ago [-]
I’m so glad as a Python developer none of this religious bullshit enters into the equation. Exactly why I left Scala behind.
antonvs 24 hours ago [-]
Your comment is just as religious as any other advocate of a programming language. You're giving reasons why the programming language you chose is the right choice. Kind of like explaining why Yahweh is the one true god, and why you left other gods behind.
newtonianrules 21 hours ago [-]
[dead]
ramon156 1 days ago [-]
What a weird take. Might as well give up on anything you care about, as its only an "x"
u_fucking_dork 1 days ago [-]
You shouldn’t feel slapped in the face if someone chooses a programming language you don’t like. Full stop.
onel 12 hours ago [-]
That's not what he's saying. It's not about the programming language. It's about people contributing, putting effort into the project and being passionate about it and then someone else throwing all off that away.
u_fucking_dork 7 hours ago [-]
Throwing all away by changing to a different programming language.
None of it is thrown away, it’s just now in a new language.
On top of that Bun is realistically a one man show with the vast majority of the code written by one dude. So the comment I replied to started from outrage and worked backwards to justify it without thinking too hard tbh.
The implication that you shouldn’t be able to change the programming language of your own project is also weird. Personally I welcome things like Typescript being rewritten in Go
fragmede 6 hours ago [-]
When other people start to relying on you, you do develop some level of responsibility to them. That's not weird at all. If your project is your cat's website code, no one cares if it breaks. If you're project is something my project relies on that I use to put food on the table, yeah it's your project, but it's not remotely weird for me to have some sort of an opinion if I think you're yolo pulling rugs, and using hope as the strategy that you don't pull one that I'm standing on.
u_fucking_dork 45 minutes ago [-]
In your fantasy scenario moving to Rust over Zig 0.16 would good
insane_dreamer 1 days ago [-]
This makes a lot of sense.
For example, we (and many others) depend heavily on numpy. It's been around for decades and heavily battle tested. If someone came out with a new version of numpy vibe-code rewritten in a week, with assurances that "all tests pass", do you think we would adopt it? Absolutely not. We would have no confidence that there aren't some latent bugs or that we can fully trust the results.
It has nothing to do with AI having rewritten it, it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
sigmar 1 days ago [-]
>it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
"it was made in a week" gets repeated a lot on HN, but the PR wasn't a release. They've been working on the rust rewrite for more than a month and it hasn't shipped.
bastawhiz 24 hours ago [-]
One week to four weeks doesn't make it better.
antonvs 23 hours ago [-]
Did you miss the part where they said "it hasn't shipped"?
insane_dreamer 16 hours ago [-]
> They've been working on the rust rewrite for more than a month and it hasn't shipped
doesn't make any difference
the point is, users haven't been using it for years, like the original
there is absolutely no way that you can internally test all the use cases that users encounter, especially with such a large code base
ghusto 23 hours ago [-]
That's like saying "It took me a month to hand-make this cupboard. If someone made a cupboard in just one day using a machine, do you think I'd trust it?".
happytoexplain 22 hours ago [-]
Only you can prevent tangential arguments about analogies.
ghusto 12 hours ago [-]
Took me a while to understand what you meant by this, and I hope I got it right: If I use a simile or analogie, people will argue about that instead of my point?
Possibly, but my simile was strong enough to be an example. In fact, it's something that happened (still happens to some extent) in carpentry. Note well the absense of any argument against it, but the downvoting.
ChrisArchitect 23 hours ago [-]
Related:
yt-dlp - Bun support is now limited and deprecated
I feel like all the replies have totally missed that this Rust port has (reportedly) thousands and thousands of "unsafe" statements and no human review; I'm no rust dev but that doesn't make me very confident, and probably won't consider Bun for new projects either
1 days ago [-]
krzyk 1 days ago [-]
That name is quite near the infamous Electron, is it similar?
chuckadams 1 days ago [-]
I'm not joining the chorus condemning Bun for the vibe-rewrite, and I think it's fascinating whether it turns out to be a complete trainwreck or not. But FFS, it should have been a separate repo.
tln 1 days ago [-]
What? Why? Git has branches...
punchmesan 1 days ago [-]
They're two completely different codebases... even if they are 100% feature parity, it's 100% different code. They should absolutely be separate from each other, with different issues lists. Clean separation of two different codebases isn't a strange concept...
tln 1 days ago [-]
Its not 100% different code though. Docs, build instructions, C++, Typescript...
The issues should absolutely be kept. The rewrite was file by file translation so logic bugs would remain. It's valuable to ensure the memory bugs are in fact fixed. Starting the issues from nothing does not make any sense to me.
wiseowise 1 days ago [-]
Judging by the comments, Bun as a company doesn’t give a single shit about community. The only reason it is in the same repo is tracking down issues, discussions, etc. Those would be hard to migrate.
chuckadams 1 days ago [-]
Right, but it's my understanding that it was done as a PR that was merged to `main`. Sure, anyone could find the last Zig commit and branch off of that, so I guess it's all po-tay-to po-tah-to.
feverzsj 1 days ago [-]
I doubt any sane human will continue using Bun.
chuckadams 1 days ago [-]
In this industry, that leaves most of us.
pessimizer 1 days ago [-]
This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
Still, I can't help but entirely support it. I don't want hard dependencies on gigantic megacorps, or on any single provider who can go rogue. Should have always been able to switch between them, and any of them who made that difficult should have been the ones to be shunned. Completely dropping support for bun is equally bad imo, because now your choices are limited to Microsoft and deno, making deno close to a single point of failure.
Although I have to wonder what would happen if Anthropic threw a couple of bucks at electrobun (lol, not really.)
wiseowise 1 days ago [-]
> This whole thing of shunning bun is a goofy protest against AI in general by a bunch of programmers about to transition from vastly overpaid to mostly unemployed, sometimes thinly disguised as quality concerns and piggybacking a little bit on the anti-"rewrite it in rust" train.
It is interesting how you find millions of people put on the street “goofy”, all while concentrating wealth in the hands of a couple of hyperscalers.
Rendered at 19:51:45 GMT+0000 (Coordinated Universal Time) with Vercel.
I think that in my mind, it was always some sort of weather related bell, like you ring it, when the weather changes.
Hopefully the sheep reference will help me remember.
I went hiking in Albania recently. I saw many sheep grazing in the mountains. I wondered about the sheep chosen to wear the bell. Like, was it the same sheep every day? Did the chosen sheep think, "Fuck me this thing is annoying"?
I think we need to smell the coffee and review npm and scrutinize it because it is getting dangerously out of hand.
At the least, my interpretation of deno lore is that they tried to ditch npm and found this limited their adoption so significantly that they had to patch it back in. That would provide sufficient warning to me that attempting to move away from npm was unwise.
Do you know of a better alternative for JS/TS that has all the popular packages?
Tedious, but makes the "npm hacked again" posts mostly moot.
This is ridiculous and the response is entirely expected, it’s not about the code anymore, it’s about people. If you claim that doesn't matter, then I think the user response tells you otherwise. It signaled that Bun was not being transparent while asking people to trust it as a core runtime system. Why would I trust a runtime that actively would just do major changes so callously? There’s a balance between all of this. You don’t need to be as methodical as Python is now with PEPs. I think Swift got similar crap, though, nowhere as bad when it rolled out major language changes out of the blue to support Apple’s own product needs a few years back. This was kept secret and released in one burst, bypassing the entire Language Evolution process they crafted for Swift. Apple’s actions are more understandable by the nature of the company wanting to keep some things under wraps, even though it did erode trust somewhat. Apple is now a 50+ year old Fortune 100 company and Apple engineers really just kinda demurred on the bad taste it left in the community’s mouth, but at the same time, what do you expect from a company with a long history of being rather tight-lipped on major product changes. Bun has not really built this reputation nor has their parent company, but they are asking for that here and I just don’t think they have the leverage to do it.
They could have done this more methodically, made sure that the community and industry were okay with it. Maybe they actually did this more thoughtfully behind the scenes and this entirely a marketing stunt, but their lack of transparency at this moment makes it difficult to give them the benefit of the doubt. Trust is currently in short supply, burning it up on stunts like this is stupid.
One of the responses to this announcement was Jarred asking: “What issue did you run into with the Rust rewrite? If there’s something specific I’ll fix” Dude, this is a comms problem, not a technical problem. Refusing to accept that makes the situation worse and I think it is completely believable if Bun eventually dies over this because it’s clear the folks running the show don’t understand part of the process of winning customers is to build a community where Bun is just considered the obvious choice. I remember awhile back they also forked Zig to do some “optimization” that was pointed out by Zig maintainers to be worthless. There’s a pattern developing here and it’s not a good one.
Their whole point was "drop in node replacement" - instead of hitting that target they built an entire framework of tools, seemingly changing focus every month or two, and are now rewriting all that to a new language.
I am building a new JS runtime called cottontail.
It’s just a prototype now but the goal is to have a huge standard library powered by native zig such that you don’t need npm.
So you’re right that npm is a disaster and I’m working on solving.
npm install pulls in my dependencies plus god knows what else at god knows how many levels. 500MB of dependencies? The dependency's dependecies are not reviewable.
I wish people would stop trying to compare NPM to PyPi and others. NPM is an unfixable disaster because of the entire mindset and ecosystem around JavaScript.
This is not as big an experiment as that. But, for software dev, it feels very significant.
I'm also glad I don't use bun
Part of me thinks it's a mild overreaction. It's not like people audit every line of kernel/driver/BIOS/EFI code before running Linux? As long as the tests pass and the performance doesn't regress and it's secure... why are people so mad that it was vibe coded? Is it because it was an irresponsible thing to do? Maybe?
I don't know, I see both sides.
To be pedantic, tests prove that the code passes the test suite, nothing else. They do not prove by themselves that the code is correct, secure, maintainable, efficient, etc. Those are much harder to measure and have a ton to do with organization, architecture, culture, shared knowledge of the maintainers, etc. All of which is lacking during and after this rewrite.
Because the chances that they had a test suite that was actually comprehensive enough to guarantee correctness through this kind of refactor are approximately zero.
Normally we combine tests with careful "correctness by construction" design work and code review because we know that tests aren't sufficient.
That's basically Torvolds full time job?
They mention nothing about agents being used, rather focus on humans in the review cycle and some sort of gated roll-out process. Why we would bin these practices in the name of a faster release cycle is an important question & debate.
I have no idea whether the new or old code is/was good, just pointing out what seems like a plausible thought process for people who object to this rewrite.
I mean, until very recently, the idea that one million lines of code could be written (rather than mechanically translated) in a month was unbelievable.
It is clearly the case that times have changed since the tools have been updated. So if we challenge one assumption, why not also challenge the other?
Bun presumably will have access to Mythos, which is purportedly reviewing million line code-bases (Mozilla, etc.) and uncovering real value for the devs of those projects.
I find it hard to deny extrapolating these trends to this Bun rewrite.
It is still unbelievable, because it still has not happened in this case. The agent wrote it. Nobody thinks it's unbelievable that an LLM can generate a million lines of code in a month. You either do not understand what the detractors are saying or are arguing in bad faith
I'm saying that AI is going to develop software from here on. I don't think you can expect that a human is going to review every line of code. Not that it's good, but that's just how it is. It's not so different from manufacturing. A human is not reviewing every weld. I see a lot of sloppy beads, but in a lot of cases, it's good enough.
On civil engineering projects, I’m pretty sure a human reviews each weld. For mass-produced things, maybe not, although a company would not look good in a lawsuit if they had inadequate inspection procedures which allowed a fault causing injury or death to occur.
Nope. It’s sampled.
> Electrobun aims to be a complete solution-in-a-box for building, updating, and shipping ultra fast, tiny, and cross-platform desktop applications written in Typescript. Under the hood it uses bun to execute the main process and to bundle webview typescript, and has native bindings written in Objc, C++, and several core parts written in zig.
Bun has been almost entirely worked on by LLM's for ~6 months now, long before the Rust re-write (source: https://x.com/jarredsumner/status/2054525268296118363). It already has been proven that LLM's can maintain such codebases.
>It already has been proven that LLM's can maintain such codebases.
Proven is a strong word. In my experience AI fails miserably at anything beyond junior level tasks. We will see soon, once bun goes into production.
It's very easy to throw shade like this on software if you've got a bugbear with it. I'm sure you can even come up with a bunch of these "stability" problems when challenged on it. I know I could, for basically any large piece of software that I've ever used.
But really, is bun worse in this regard than any other similarly ambitious open source software within it's first few years?
this is a piece of software with no architecture, and whose owners have no regard or respect for architecture. I can virtually guarantee that on average every bug they fix will create one new bug, because that's what it's like to work on software with no intentional architecture
I am asking if we are expected to understand this hypothetical condition about all possible tools that we use. Should I have to worry that something is written in Python when it should’ve been written in C? It just seems like that in order to have a big concern here, I had to be really invested in what language Bun used. I guess the whole matter makes more sense if people are REALLY mad about something else and the choice of language is supposed to serve as a more respectable thing to be mad about.
I think that using AI to translate bun from zig to rust might produce a good starting point. But it was done one file at a time, with minimal human review, and I'm skeptical that the result is quality maintainable code.
I dunno. I think my sense here is that the bun maintainers did something shocking and dramatic using AI and people are shocked and dramatized. They're not WRONG to be so. But I don't know that the shock comes out of any generalized duty of care we have toward open source tooling. I think the uncomfortable point that bun has been releasing for 6 months with smaller AI code edits hasn't really been reckoned with. If we were actually this invested in what was happening, the migration would've begun months ago when it was clear they were using agents to ship code faster than they were willing to review.
What is being expressed here about Bun is using the language of due diligence but doesn’t seem to adhere to any of the sensibilities. Should we all be auditing our toolchains to understand internal decisions that each toolmaker undertakes? Maybe! DO WE? Absolutely not. The level of scrutiny bun is getting is *unusual*. They just did an unusual and dramatic thing, so it’s not surprising. But I just don’t believe that bun is being deprecated due to normal engineering discipline that we are constantly carrying and applying everywhere. That’s…just hard to buy.
Is it? Seems like bugs in Claude Code are getting out of hands. That project has a bit more lifetime.
I don't think that's true? The likes of Chrome, Linux, curl, sqlite, etc, are much more widely used.
They don't get enough credit for being right in the middle of a revolution, yet still managing to ship something that largely works incredibly well, because this thing is a workhorse.
It hasn't. Those are two different scenarios. The first is individual PRs into an existing, majority human-authored and understood codebase where the PRs are initiated and merged by humans even if the code is AI generated. The second is AI rewriting AI written code that no human eye has seen. Bun took a conservative, transliteration file-by-file approach so they still understand the data structures and architecture so they will probably be okay though.
So what you’re saying is that this boycot is 6 months overdue?
Nobody understands the code, nor will they be able to maintain it without AI service as an external dependency. Give me a break, I'm not running that monstrosity on my machine. Everyone running production software should move away from Bun purely as a technical decision.
2. It's amazing that a CLI wrapper is as buggy as it is.
3. Nevertheless, it's useable, and maybe for a CLI that's enough. I don't want a JS runtime running production to be the same mess.
It’s approaching being as buggy as claude code which I’ve had to stop using even though I have 6 months free of max because it just crashes and freezes all the time.
When you touch a file you have an opportunity for code clean up, add unit tests to ensure your changes break nothing, and refine the code.
> A CVE wasn’t announced for an HTTP Request Smuggling vulnerability
Even before the acquisition of Anthropic, there had never been a single vulnerability report.
https://github.com/oven-sh/bun/security
Do not use this in production.
https://xcancel.com/YoavCodes/status/2058170216408813583#m
The bun rewrite was Anthropic's Vietnam and the open source community needs to react and and build resistance.
Maybe someone has more info of them mentioning that.
How does one determine what "adequate" looks like for a million lines of code?
You can't fit a million lines of code in a 1M token context window unless every line of code is one token. So you're just sort of praying you spend enough time/money burning tokens to shake out all the stuff that's bad or wrong.
And also that it’s capable and trustworthy enough to rewrite the whole runtime in another language flawlessly such that no human needs to code review?
Idiocracy.
Me, I still have to be competent to succeed. I don't just get to declare that because I used AI the effort was a success, and I have 0 desire to work with those kinds of people.
This seems like Tauri 2.0 - wrap something in Rust and claim the memory safety issues are gone.
What a slap in the face to all the Zig developers that spent their time, effort and probably even some money contributing to it.
Edit: You mentioned tuition, so you must be American. I am British and our social class "system" is different. I'll leave my comment as some may find it interesting.
None of it is thrown away, it’s just now in a new language.
On top of that Bun is realistically a one man show with the vast majority of the code written by one dude. So the comment I replied to started from outrage and worked backwards to justify it without thinking too hard tbh.
The implication that you shouldn’t be able to change the programming language of your own project is also weird. Personally I welcome things like Typescript being rewritten in Go
For example, we (and many others) depend heavily on numpy. It's been around for decades and heavily battle tested. If someone came out with a new version of numpy vibe-code rewritten in a week, with assurances that "all tests pass", do you think we would adopt it? Absolutely not. We would have no confidence that there aren't some latent bugs or that we can fully trust the results.
It has nothing to do with AI having rewritten it, it has to do with being battle tested over time. If a team of humans had rewritten it in a week, I wouldn't trust or use it either.
"it was made in a week" gets repeated a lot on HN, but the PR wasn't a release. They've been working on the rust rewrite for more than a month and it hasn't shipped.
doesn't make any difference
the point is, users haven't been using it for years, like the original
there is absolutely no way that you can internally test all the use cases that users encounter, especially with such a large code base
Possibly, but my simile was strong enough to be an example. In fact, it's something that happened (still happens to some extent) in carpentry. Note well the absense of any argument against it, but the downvoting.
yt-dlp - Bun support is now limited and deprecated
https://news.ycombinator.com/item?id=48238789
The issues should absolutely be kept. The rewrite was file by file translation so logic bugs would remain. It's valuable to ensure the memory bugs are in fact fixed. Starting the issues from nothing does not make any sense to me.
Still, I can't help but entirely support it. I don't want hard dependencies on gigantic megacorps, or on any single provider who can go rogue. Should have always been able to switch between them, and any of them who made that difficult should have been the ones to be shunned. Completely dropping support for bun is equally bad imo, because now your choices are limited to Microsoft and deno, making deno close to a single point of failure.
Although I have to wonder what would happen if Anthropic threw a couple of bucks at electrobun (lol, not really.)
It is interesting how you find millions of people put on the street “goofy”, all while concentrating wealth in the hands of a couple of hyperscalers.