Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun support is now limited and deprecated

github.com

Post reply on HN
Print view View original

171–180 of 646 posts

Re: Bun support is now limited and deprecated

#171

Post by fmbb »

johnfn wrote: post #125
hypeatei wrote: post #105

Earlier quoted context omitted.

I believe you contradicted your first point by following it with "If Bun starts having more bugs and feeling like worse software" ...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on. As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your c…

Bug counts are numbers. Memory usage and performance are numbers. Eventually those numbers get so bad that you leave.

Well if you promise support you promise support.

You cannot take back a promise after you make it. So if you discover bugs later you cannot just leave.

This script is just a JavaScript helper to bring full YouTube support to some media download tool. It does not seem important to anyone that executing it using Bun is supported. They support the Deno and Node runtimes.

Re: Bun support is now limited and deprecated

#172

Post by guilhas »

burnte wrote: post #154
johnfn wrote: post #73

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…

> This decision seems to based more in politics than engineering. You are 100% right. This is a decision made on VIBES and not evidence. The proof is here: > Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid. The…

So a vibed decision to reject vibed code. Minus minus equals plus?

Re: Bun support is now limited and deprecated

#173

Post by fdsajfkldsfklds »

hathawsh wrote: post #165
fdsajfkldsfklds wrote: post #126

Earlier quoted context omitted.

Engineering decisions and the resulting output. We've known for decades that machine-translated code is garbage, and should only be done as a last resort.

Your HN account is too new for me to be sure whether you're being sarcastic or not. Perhaps you know, or perhaps you don't, that all code is machine-translated, even assembly language. None of it is perfect, but it's not garbage. Today's AI merely provides a new level. It's a weird, non-deterministic level, but hiring an employee to write code for you is similarly non-deterministic.

Right, and that's why Mel was a true programmer!

Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.

Re: Bun support is now limited and deprecated

#174

Post by wizzwizz4 »

olzd wrote: post #143
wizzwizz4 wrote: post #78

Earlier quoted context omitted.

Relevant reading: https://nesbitt.io/2026/02/16/changelog.html > Removed: mathjs dependency. 14MB, 200+ functions. Twelve functions used. Added: Custom math utilities module (src/math-utils.js). Addition, subtraction, multiplication, division, a handful of trig functions. Co-authored-by: chatgpt. Changed: Bundle size reduced by 68%. Build time down from 12s to 4s. Module: 47 lines across 1 file. 0 tests. 0 dependenci…

Are you aware this is satire?

Yes, it says so right under the title. But it's not wholly fictional: this happens all the time, to the point we have a name for it (Not Invented Here syndrome).

That it took so long before they started trying to phase out their home-rolled library for the "hard cases" is somewhat unrealistic, although possible in a sufficiently-dysfunctional organisation. Some of the details about the problems of their homespun library are clearly anecdotes translated from other settings, and are unrealistic in the context of a mathematics / finance library. (They only noticed that interest calculations were wrong when a customer complained? Seriously?) The development of 6.1.0 (via 6.0.0) taking only two weeks isn't congruent with the rest of the story, although it may be realistic for AI-driven development (with which I am unaccustomed).

But otherwise, this is one of the more realistic satire pieces I've read.

Re: Bun support is now limited and deprecated

#175

Post by Robdel12 »

johnfn wrote: post #73

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…

I have no idea how that’s what you get from this. I don’t want my project using any tech that decides to take 6 days to rewrite the entire library with AI. That is at its core an engineering decision.

No healthy engineering team is going to do that. And I’d want to distance myself as far as I could from a project that behaves like that.

Re: Bun support is now limited and deprecated

#176

Post by the_gipsy »

johnfn wrote: post #73

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…

Why wait?

Seems reasonable to preemptively drop support and let someone else either suffer the fallout, or get proven wrong and just pick up support again. It's not for a lack of people motivated by IA. Unless the motivation is more "use my IA generated content" than "actually consume IA generated content", of course.

Re: Bun support is now limited and deprecated

#177

Post by guilhas »

johnfn wrote: post #73

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…

Isn't that what Bun/Anthropic did? A rewrite based on vibes?

Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse

All Bun devs are happy to change programming language?

When their competition is already in rust and more mature

While using the LLM that is now paying their salaries. Kind of a conflict of interest

Even a major version upgrade is enough for me not to touch it for 6 months, let alone a full rewrite

Has Bun posted any analysis and shown the data?

Re: Bun support is now limited and deprecated

#178

Post by gpm »

johnfn wrote: post #145
gpm wrote: post #98

Earlier quoted context omitted.

> 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.) On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to…

> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything. I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable…

> Saying "because they vibe coded we are dropping support for Bun" sounds political.

I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in.

It happens that in this case that I'd disagree with their politics if that's why they are dropping Bun support - I think there's a great deal of value in moving to memory safe languages, little harm in accepting anthropic compute and funding to do so, and that use LLMs themselves is roughly value neutral (though many uses are very much not value neutral). That said reasonable people definitely disagree with me.

Re: Bun support is now limited and deprecated

#179

Post by t_mahmood »

johnfn wrote: post #73

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…

So, let's see here. Here we have a program, that is used to install scripts from source that has been targeted, and breached multiple times last few months, can run arbitrary code on millions or billions of user computer, servers. And, it was ported to another programming language, resulting in 1m LOC, in 7 days for publicity stunt of a LLM company

Even multiple people can not go through 1m lines of code for any kind of vulnerability in 7 days, let alone 'observe' more segfaults, OOMS, unsafe behavior, on who knows how many possible ways things can go wrong in this new condition.

Only guaranty is 99% tests passed, and the engineer who is paid by the same LLM company.

How in the world, any sane engineer would agree, this would be remotely a good idea to continue using this tool, for a chance that such a expensive change won't actually land in production?

Re: Bun support is now limited and deprecated

#180

Post by karel-3d »

getcrunk wrote: post #156

It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers. Or did we forget software inherently is opinionated

exactly... and it's not like it's hard to fork and just raise the minimum version. It will probably be just one number somewhere (I haven't actually looked.)

if it works, it will keep working. they just don't want to support and maintain it and solve issues.

Post reply on HN