This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement.
I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here.
show comments
adamtaylor_13
We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out.
It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually has when they just use "vibe coding" as a general LLM usage slur.
I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster.
show comments
hootz
Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
show comments
maxloh
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 entire rewritten codebase. There are just too many lines of code, 1 million lines to be exact [1].
This is about the rust conversion but that has not been released.
> Due to foreseeable compatibility and security issues
Hmm, Zig bun crashes plenty.
I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites.
Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would be good to see.
I hope Bun.rs is 1.4 or even 2.0 and not a minor release, with some alpha/beta releases.
therepanic
To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.
insanitybit
They foresee potential issues in the future, so they deprecate now? I mean, whatever lol do as you like, but that's an odd choice.
sashank_1509
Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.
apitman
Say what you will about Rust vs Zig as languages, the Zig toolchain is definitely the easier of the two to integrate into another project.
show comments
merb
Google did something similar with golang. Of course it was a tool based rewrite and they did lots of tests but some bugs still emerged. People should stop being mad about a company that delivers a tool that is about shipping software faster. The world does not resolve around high quality software, the world resolves around things that might need a reboot every other day, that was never touched for over 2 years. Things that somebody did once and it worked but most people do not understand it because of the aweful code.
Yes of course we still need high quality code in some parts, but most parts of the world is already running on software that is way worse than modern vibe coded things
show comments
yanis_t
Do we know which model was used for the rewrite?
fastball
The "to vibe code or not to vibe code" holy war is now in full swing.
show comments
cabernal
there could be recommended runtimes, but shouldn’t the runtime be user-configurable anyway?
show comments
thot_experiment
I assume they need to do a bunch of WebAPI bullshit to get around Youtube's draconian policies, but maybe one day https://txikijs.org/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.
satvikpendem
As long as Deno support is still there I'm not sure why you need anything else. It's not vibe coded slop for one.
show comments
antonvs
Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.
show comments
mvdtnz
Wow, bun support was just added in November last year (I think). That's a lot of work to throw away, but you can't argue with their reasoning.
show comments
meindnoch
Good news!
umvi
Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps?
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
show comments
muglug
This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.
This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement.
I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here.
We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out.
It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually has when they just use "vibe coding" as a general LLM usage slur.
I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster.
Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.
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 entire rewritten codebase. There are just too many lines of code, 1 million lines to be exact [1].
[1]: https://github.com/oven-sh/bun/pull/30412
This is about the rust conversion but that has not been released.
> Due to foreseeable compatibility and security issues
Hmm, Zig bun crashes plenty.
I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites. Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would be good to see.
I hope Bun.rs is 1.4 or even 2.0 and not a minor release, with some alpha/beta releases.
To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.
They foresee potential issues in the future, so they deprecate now? I mean, whatever lol do as you like, but that's an odd choice.
Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.
Say what you will about Rust vs Zig as languages, the Zig toolchain is definitely the easier of the two to integrate into another project.
Google did something similar with golang. Of course it was a tool based rewrite and they did lots of tests but some bugs still emerged. People should stop being mad about a company that delivers a tool that is about shipping software faster. The world does not resolve around high quality software, the world resolves around things that might need a reboot every other day, that was never touched for over 2 years. Things that somebody did once and it worked but most people do not understand it because of the aweful code. Yes of course we still need high quality code in some parts, but most parts of the world is already running on software that is way worse than modern vibe coded things
Do we know which model was used for the rewrite?
The "to vibe code or not to vibe code" holy war is now in full swing.
there could be recommended runtimes, but shouldn’t the runtime be user-configurable anyway?
I assume they need to do a bunch of WebAPI bullshit to get around Youtube's draconian policies, but maybe one day https://txikijs.org/ will solve all problems with embedding javascript. I believe, and maybe the strength of my belief will be enough.
As long as Deno support is still there I'm not sure why you need anything else. It's not vibe coded slop for one.
Reason #2 is purely speculative. It’s disappointing to see technical decisions being made on such grounds.
Wow, bun support was just added in November last year (I think). That's a lot of work to throw away, but you can't argue with their reasoning.
Good news!
Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps?
There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.
This like if BitTorrent cut off Windows support over objections to Microsoft embrace/extend/extinguish. It’s a slightly incoherent position.