Completely unbased, but I don’t want to have to do anything with bun anymore. It’s just a gut feeling, but I don’t trust them and support them.
They fork Zig to utilize LLM rewrites and build something the Zig team clearly disregarded (non-deterministic compiling)
And now like a whiny baby they LLM rewrite to Rust. There is a very real chance that Zig design philosophy got them to the point where they are now by enforcing to make the tough but precise decisions and the Rust rewrite is the start of the downfall.
It’s purely politics-based not technical, but it seems like bun is full on pampered by Claude. So much that I wouldn’t wonder that the next marketing piece of Anthropic is. Claude Mythos rewrote leading 950k LOC JS Runtime to Rust.
Yeah I also noticed this irony. In addition to accusing the rewrite to being political and not technical, while their whole comment is being political not technical.
Ah, fair enough then, you mean want to clarify that a bit as it can be interpreted both ways. And the whiny baby part seems a bit uncalled for and distracting from the point you’re trying to make.
Don't give them too much credit, they responded to other comments clearly referring to the developers' comments on twitter about his technical motivations. He's just backtracking now due to your comment.
I meant the developers motivation with "whiny baby" and I take the point that this was over the top and I could’ve found better words.
But I meant that my comment is "politics-based and not technical", because the gut feeling is more based on my reading of soft factors than it is from in-depth technical analysis of everything involved.
How can you be so blind? This is all a marketing campaign by anthropic. No more no less. The developers doing the rewrite have no voice at all in this game.
I'm team Zig in most cases but I genuinely think they are better off with Rust. They have had a lot of buffer overruns and segfaults as a result of undisciplined Zig code. I think Rust actually is a better technical choice for them.
I don't think that's going to save them. There are big problems and little problems. RAII+ownership/borrowing solves some memory and file handle issues. But the big problem and this happened before the rewrite, is that they have ceded the system level. Which locks the project into a local minima.
It's not a "your holding it wrong" problem it's a you fundamentally have no idea how your own program works past 1 or 2 level of indentation in most places. If the LLM says that something isn't possible you just have to take it at it's word.
> I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues
There are legit reasons to rewrite a program in a better fitting language, but as a runtime to be "tired of worrying about & spending lots of time fixing memory leaks and crashes and stability" is really borderline to me.
Also there are way more things to it than just compile time and tests: you reset mental model and will lose contributers. There is philosophy, developer skill and more attached to a language.
In this case both compile via LLVM the same and there is no performance benefit given the code is written exactly the same, so it’s developer preference, where the current head seemed to prioritize his own DX over everyone else’s.
I'm not sure if the 50% of people defending the whole rewrite live under a rock with regard to the acquisition or have never worked at a US company or a deliberately naive. Companies give instructions. Nothing of this is accidental or prompted by curiosity.
I agree. From the get-go, Bun was apparent in its design philosophy: we do everything you'd ever want; runtime, bundler, test suite, package manager, all in a new breaking patch each week. With each and every one blowing the established competition out, better, faster and stronger. But it was glaringly obvious that they'd do anything but Keep It Simple Stupid. It was obvious that the only production environment it would see the light of the day in the near future would be YC startups burning one after another at the speed of an accelerant. Now, they're past the point of no return.
I mentioned a similar sentiment 4 days ago in the original discussion about this project, and HN for some reason did not like that I noted Rust is used in production longer and way more than Zig is, including Firefox, CloudFlare's own reverse proxy, Discord, and many other massive effort projects that affect millions if not billions of people.
People are seriously naive about corporate incentives. You think he'll go "Yeah, it being in Zig has put a wrench in our AI usage and that's not a good look now that we're with Anthropic"? No, he'll confirm everyone's biases instead - and it's working as well as expected on this crowd.
I don't have the personal investment that you appear to have with Bun, but why does this matter? Do you scrutinize the rest of your dependencies this way?
Much of working in the JS / NPM ecosystem is already pure faith on un-vetted dependencies, and this appears no different pre or post LLM rewrite. If it satisfies the intended goal and API contract it originally did, is there any difference? Were you carefully reading the original source code before?
Enough to make judgement calls on them based on the individual Twitter posts of each of their developers? Absolutely not!
If I go beyond the initial vetting, that's a minimum of 30+ projects multiplied by however many contributors each. Without even mentioning all of their sub dependencies. It's a pipe dream to think you can ever have a complete picture of the motivations and political machinations of your entire dependency tree.
I have definitely dropped dependencies from production codebases in the past because "lead developer is widely known to be a clown". You don't need to catch everything but it's generally a good idea to have a picture of, like, the twenty most important dependencies in your codebase and the 90th percentile most notorious clowns in the community.
What is your definition of "known to be a clown"? I'm not sure how one would even begin to evaluate that at scale. Or what practical impact that would actually have for anything but the most critical of dependencies that might be too difficult to swap at will.
Hyperbole, yeah, but top 10% undesirable leads is literally thousands of people?
I couldn't imagine following the communities of even the top ten dependencies of one of our (many) projects very deeply. Every single one of them is having divisive conversations in threads like this all the time that never really lead anywhere or sum up to anything meaningful.
Sure, but you need to consider that, in this case we are talking about the language runtime. It isn't just some other library dep. It's basically the base layer of the stack. It has a huge blast radius. It is, imo, a nontrivial decision to swap runtimes. If problems emerge you can't easily plug some other runtime, that's a major technical decision and should be treated as such.
In the past at least you could assume the maintainers of the runtime had some kind of mental model of how it worked. In my view, with the way this rewrite has been approached, you can't assume that at all. It's good the test suite passes, but who knows how this will affect the evolution of the codebase? Do we even know if the code is good? How much is just slop? Tests do not test architecture. Is this new rewrite even going to be maintainable? How is the team going to get up to speed on a new codebase in a new language that the main author presumably doesn't even fully understand?
There are many reasons to be concerned. Treating this as no big deal would make me question one's ability to make assessments of technology. There's a world of difference between relying on gen AI heavily in products and leaf nodes of the stack, using it in a purely assistive way, and using it to drive a massive scale rewrite of a base component in a language the maintains team has an unproven amount of experience with. From a reliability standpoint the way this project was executed is completely preposterous, and it's very clearly a marketing stunt more than a sound technical decision on how to drive a project. It's not about the use of LLMs, it's about thee stupid and blatantly obvious generation of cognitive debt all to help sell claude. I'd have way fewer qualms if they used LLMs to do a rewrite in a way that retained developer understanding (i.e. not driven by one person and in such a short timespan that having a robust mental model, even for that person, is highly unlikely)
You're implying that reckless rewrites within the JS ecosystem are a novel event, or more specifically that surprise language changes over a short period of time are. And yet... I can think of at least six times in which exactly this has happened and little fuss was made because the polarizing element of "AI" was not involved. Not just JS to Typescript, but to Dart, Go, C, Rust, Zig, Nim etc.
From any reasonable perspective, this is business as usual in the house of cards we all operate in. Perhaps the sensationalization would be justified if the lang migration wasn't one of less correct -> enforced correctness by default?
To your point in general about maintainers holding a mental model of the runtime: I would challenge that to say that it is very likely that there is no developer who holds a complete mental model of an entire runtime at any given point. As with anything of this scale you understand individual parts in their entirety and have general assertions about the rest until specifically revisited, even if you are the sole developer. In this case specifically, Bun has been largely AI driven for quite a while anyway so it is even more unlikely that the developers ever had a complete picture in the first place. If you trusted them before, then nothing has changed.
It's not lost on me that code logic can be subtly incorrect even as tests are passing either, but there isn't exactly a lot of grey area in this particular context. Does your code compile or not? If it builds as expected, then your own unit tests will highlight the difference.
Anthropic bought it in a somewhat dumb attempt to solve their "performance" issues (not realizing their horrible code was the issue in the first place).
It probably helped them, simply because they brought in some actually competent developers.
But doing so, Bun went from being a public project to more of an internal tool for Anthropic, spoiled for now with AI money and losing quite a bit of focus.
Let's hope that when the bubble pops, some of the Bun effort could at least be salvaged. I don't see Anthropic maintaining it long term, they are simply not in the business of selling support for a runtime nor have the (Google) scale justifying maintaining one on the side.
Yep, the Anthropic acquisition, this petulant Rust rewrite, and bun's increasingly buggy releases (slop) have caused me to migrate my projects (personal and work) to nodejs+pnpm.
The risks of using bun are no longer just those concerns around a newer tech and "drop-in" replacement for nodejs. Now you have to marry Anthropic, Rust, and a founder with conflicting priorities.
How exactly will waiting a year or two make this effort appear “characterized by impatience and grumpy annoyance”, as opposed to the people right now who are loudly bemoaning an engineer trying something out as an experiment?
They fork Zig to utilize LLM rewrites and build something the Zig team clearly disregarded (non-deterministic compiling)
And now like a whiny baby they LLM rewrite to Rust. There is a very real chance that Zig design philosophy got them to the point where they are now by enforcing to make the tough but precise decisions and the Rust rewrite is the start of the downfall.
It’s purely politics-based not technical, but it seems like bun is full on pampered by Claude. So much that I wouldn’t wonder that the next marketing piece of Anthropic is. Claude Mythos rewrote leading 950k LOC JS Runtime to Rust.