I'm actually excited for somebody trying experimenting with automated translation, but I'm afraid this will be lots of backwards compatibility issues.
I started looking at the commits, and it's basically solving the ,,tests not pass'' problem by changing the tests themselves. The real work of making it working on programs that are already deployed will be just starting now.
The only silver lining I see is that the server side JS community for some reason is already used to breakages all the time.
Turns out "its just an experiment, you all are overreacting" was just a lie to damp criticism.
Love seeing the tests themselves getting modified, with random `sleep(1)` thrown around in a few of them. This bodes well, I pray some idiot at some large AI co actually ends up using this garbage in prod
So the geniuses in the datacenter prefer to rewrite the full codebase in another language instead of maintaining and improving its own fork or contributing to make the current language better.
Impressive to rewrite 1MLOC in a week yes, but this is more of a job of a million monkey programmers crammed in a datacenter than a bunch geniuses. And I would know, since I'm a monkey programmer who is in danger now... Or maybe the Zig team is in a greater danger, since their brains hold the genius juice the clankers are missing and they should have it by 2027...
If this goes wrong even in the slightest, the ridicule about a drug dealer getting high on their own supply will be neverending and grim.
PR so thick, the page failed to load the first time I opened it, and the comments still continue to fail to load. Absolutely hilarious. Though that may be just GitHub having a normal one, hard to tell these days.
1 009 257 lines added
4024 lines removed
6755 commits
2188 files touched
I haven't the slightest clue how anyone would even remotely hope to review this. I guess by just using even more AI? Or maybe by throwing some über hardcore lint pass onto it? It really seems like more an exercise in risk assessment than code review.
Say what you want, but for people building products on Bun, this is bad news for the foreseeable future.
I hope the Deno lot take the opportunity to capitalise on this
Wondering what they will do when rust rejects a pr from them.
Why didn't they ask Claude to remove all of the `unsafe` at the same time??
Has he estimated the token cost for this (if he had to pay that is)? I'm curious how much this would cost a paying customer.
How they gonna do refactoring, bugfix or other maintenance on generated code? Ask LLM?
How does the no async work? Would have thought Bun would need that
I'm curious how much dollar in LLMs this rewrite cost
This canary will never leave the mine. (unless Anthropic opens their wallet again)
>No async rust.
I wonder why does that deserve an explicit statement? Is there anything wrong with async rust?
Hey, it forgot to change the README!
The follow-up PR removing the zig source files being auto-tagged by bun's own CI as "ai slop" is so funny
Deno's approach from the beginning seems to have proven out.
"And Icarus laughed as he fell, for he knew to fall means to once have soared"
It's interesting that the developer who spearheaded the hype of Zig abandoned the engineering without addressing the segfault. They could have also taken the approach of gradually porting from Zig to Rust via FFI. Yes, this is a slop show by the AI lab.
Now translate it into zig!
vibe coders keep saying that now you can have 100x productivity, that you can write a million lines of code in a week and do what would take a team of 10 experienced developers a year.
where are all these million lines vibe coded projects? I don't see them. its all hype
This will go down in history as the biggest mistake of software engineering of all time.
Bun is the runtime of Claude Code, which is the core product of a trillion dollar company, which now sits on a vibe-coded app, where not a single person in the world has a proper mental model of.
Anyone using Bun in production excited for this release? (other than Anthropic of course)
HN overreacting again.
I trust Jarred to make the right decisions regarding bun, which seems to be his passion. Bun has always been amazing since i first tried it, it had some bugs along the way, which didn’t last long.
Anything bad that comes from this, will simply be fixed.
I hope more software does this and gets rid of their segmentation fault producing code, written in c++ and other unsafe languages
I can think of a few.
Rust, Zig and TS went into a bun... /s
Still writing the blog post about this. Will share more details.
For where this is coming from, skim the bugfixes in the Bun v1.3.14 and earlier release notes. Rust won’t catch all of these - leaks from holding references too long and anything that re-enters across the JS boundary are still on us. But a large % of that list is use-after-free, double-free, and forgot-to-free-on-error-path, which become compile errors or automatic cleanup.