- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
The last three months have not looked good for Bun. It started as one of the most impressive individual engineering projects I have seen, but has now turned into this weird AI-powered creature with continuous false promises and an increasingly frustrated community.
You must log in or register to comment.
Here’s Andrew Kelley’s (zig creator) blog post on the matter: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html
Please don’t mention Rust. Rust is a great programming language. The main culprit is they used AI to rewrite it. Rust does not deserve another rotten egg thrown at it because of this.
Nobody is mentioning Rust, really. “The bun Rust rewrite” is a phenomenon. It’s not about Rust,just like “the Boston tea party” is not about tea.
I wish that was true. However, look at the title, look at how people talk about this in general. “Yo, you heard Bun was rewritten in Rust? That is soooo lame.”
Really, the title shall just say “Bun vibe-rewrite”.
it should surprise nobody that a project owned by anthropic is turning into slop.
Turning into slop?
We became increasingly horrifie tonightd at the programming practices we saw in Bun’s codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt. Jarred was already writing slop well before he had access to LLMs.
I knew it was going to happen as soon as the announcement was made. Now is probably a good time to switch the build setup back over to Node or try our Deno.
Deno has always made more sense than Bun, but all the social media influences jumped on the new thing.
I use Deno over node on new projects purely for the security model, and the fact that their standard library means I don’t need a spaghetti nest of dependencies.
Deno shares one minor annoying thing with node. The features of both slowly change over time in such a way that I need to use a specific version of Deno/Node for each project. The node community solved this with NVM. Deno has it build into the cli with
deno upgrade v<semver goes here>. The annoying thing is that it downloads a Deno binary every time instead of switching to a cached one. Great if you’re online, but if you’re on a laptop on the move it’s annoying.But knowing Deno, they’ll just build in that runtime caching in a year or so, they already do it for dependencies between projects.
Hmm sounds like the BSD folks were on to something. At what point should we not be basing our work/projects on someone else’s project (where they have sole control) where we have no say in the direction. Building code in a stack by hand also meant that that stack was gonna stick around till it was absolutely necessary after which there’s a major version update with a rewrite. But these code generators remove that inertia and this exercise is going to determine to what degree do they remove that inertia and also at what point do they tap into our worst impulses of feature creep.
Also, github has ruined git as a concept, projects don’t have everyone involved or dependent on it involved in important decisions, like something like a mailing list and what’s done in the Linux kernel vs something like bun where you only talk to the devs of bun and not the dependents of bun. That’s another rant and based on another article. But basically it’s harder to do community code for FOSS as github limits community interaction (due to design limitations from the start and then Microsoft)
Anthropic is getting what they want, and the creator of bun is getting what they want which is working on an interesting project and getting paid.
This is becoming the most interesting case of vibe coding. Bun had a pretty good thing going before all this went down. They have the investment and basically unlimited resources of anthropic, yet now still months without a release and still finding thousands of bugs to resolve.
I’m curious to see if the team eventually reverts to a zig release, or continues sinking resources into this rewrite. In the meantime, who knows how far bun will fade from relevance.
In case you’re not aware, the company behind Bun is now owned by Anthropic. So, IMHO there is no way they’ll revert the rewrite, because that decision would have to come from Anthropic and they have a ton of reputation to lose.
I guess, I could see them trying to justify a revert by flinging mud at Rust, like they did with Zig, but I don’t know if they dare.
It’s easier to punch down for Zig, because comparatively few people know it. And there’s also alreadyuv, which is a package manager for Python, written in Rust, so clearly the Bun rewrite should be possible.I’m not sure anthropic entirely dictated that bun was rewritten into rust, but I am sure they were thrilled when they got the news it was happening. I’ll mention I’m not questioning the feasibility of “Bun in Rust”, but I am questioning if the slopmachine can ever get it stitched back together and stabilized. If they end up going 6 months or a year without the release both bun and anthropic end up looking pretty dumb, and I don’t know if the dev world is going to have that kind of patience.
This initiative was promoted up as the halo project that proves LLMs are ready to take over a difficult production codebase, and the speed of the conversion was touted as proof that the era of writing code was over. At 3 months I think right now they are still ahead of any “manual” re-write timeline, but it could end up proving the exact opposite as this drags on.
Yeah, it’s going to be interesting. In principle, this is something that LLMs are good at, i.e. taking some existing thing and just translating it into a different language. But from what the Zig creator said about the Bun codebase, a lot of those hacks may be difficult to translate into Rust, and of course have a lot of potential for bugs.
And well, they do also have the problem that they cannot halfass this rewrite, which LLMs are not good at. If they publish a new version and it’s a buggy mess, it will still look bad…
In case you’re not aware
They literally mentioned anthropic by name, so I’m pretty sure they’re aware 😅
And there’s also already
uv, which is a package manager for Python, written in Rust, so clearly the Bun rewrite should be possible.Bun is a whole lot more than a package manager, though. It’s also a full JS/TS runtime, bundler and test runner. So I don’t think that’s a great comparison
Well, Anthropic have previously used their near-infinite investor money to give out tokens to open-source projects as a publicity stunt. And it just seemed so impossible to me that they would revert when they’re owned by Anthropic, that it made me unsure, if they’re aware of this ownership… 😅
And good point about Bun being more than just a package manager.
uvis also more than a package manager. Pretty sure, it could also be referred to as a bundler and a test runner, and I’ve seen it used to manage the install of different Python runtime versions. But yeah, being a full language runtime by itself, that is the big one here.I mean, there’s also a near-infinite supply of toy programming languages being implemented in Rust, if the LLM needs something to ripoff, but yeah, a production codebase will be magnitudes more complex, of course.
Unless it’s forked, I don’t think anyone will trust it.
Letting a slop machine rewrite your Bun as slop? And it produces slop itself afterwards? NO! IT CANNOT BE!! YOU MUST BE PROMPTING IT WRONGGGGGGGG!!!
How could this be possible?! They even used AI?! 🤦♂️
In point of fact, the language devs of Zig (what Bun was originally written in) have seriously distanced themselves from Bun, as a result of a number of things - not least of which, because evidently the Bun dev was just… doing a lot of crazy, sketchy, cowboy shit that the Zig lang devs found aggravating, because it was basically the showcase project for Zig, and it was honestly kinda making the language look not awesome.
Must’ve forgotten to add “make no mistakes” to agents.md.
Also include “no hallucinations”
