Live data from Hacker News

Bun support is now limited and deprecated

github.com

391–400 of 646 posts

Re: Bun support is now limited and deprecated

#391
post #86

Earlier quoted context omitted.

IMO the source of the new code is less important than the sheer volume of it. Bun does not need to be entirely rewritten; certainly not over a period of a week, possibly not even over a period of a year. Stability is hard-fought and battle-tested. Everyone has a plan until they get punched in the face; and every repository has passing tests until it runs production code.

How many lines of translated code would have been acceptable? What about before AI all the machine translated projects that people used for years without a single complaint? The person who did this was the lead for Bun from the get go no? So it stands to reason that they are one of the highest authorities in Bun itself.

What is the essence of a program?

The name? No.

The author? No.

The test suite? No, testing is hard and most projects don't do enough of it.

The code? Not really, code can be rewritten.

The history of the program being executed by its users? Ding ding ding. Yes, it's this one.

Bun no longer exists. What exists now is a program that has the potential to be Bun but at this time is not Bun because it has no history of being executed as Bun.

If the rewrite has been done piece-by-piece or over a longer time period then this history could have been built up over time. As such we will have to wait a while for Bun to exist again.

Re: Bun support is now limited and deprecated

#392
post #2

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.

According to the bun team, it was already vibecoded for months before the Anthropic acquisition.

Probably a lie tbh

Re: Bun support is now limited and deprecated

#393

Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?

Because for a lot of AI fans (not all, I know), it's like a religion. They aren't content to live and let live and let history show whose approach to building software is better, they insist that everyone has to agree with them. I have that situation at my job and it drives me insane that honest technical disagreement isn't allowed when it comes to AI.

Re: Bun support is now limited and deprecated

#394

Earlier quoted context omitted.

You are putting words in my mouth, I never said anything about such a stance. The vast majority of new software is written using AI. The problem is not that it is written by AI, but rather than some people treat it like a black box. It is entirely possible to use AI to write code and verify that it is correct. Even Linus Torvalds is allowing AI generated code into the Linux kernel as long as it's managed properly.

>The vast majority of new software is written using AI. The problem is not that it is written by AI How on earth does this follow? It's common, so it should be accepted without scrutiny? >The problem is not that it is written by AI, but rather than some people treat it like a black box. Yes, and guns don't kill people. Obviously the issue has two facets. It would be irrational to say "AI is flawless" or "humans are f…

You are referring to black-box coding, not vibe-coding. There is no strong formal definition of that word. Is there evidence that they just fired off the LLMs and didn't review or test the new bun code?

Re: Bun support is now limited and deprecated

#395
post #382
post #226

Earlier quoted context omitted.

> Stopping maintaining and testing support for upcoming versions is cheaper than doing that work. If it’s based on predictions of how some alpha software might turn out in the future then I don’t see how you can claim it’s cheaper. If a bunch of new bug reports came in then you said no, then everyone would understand. This is pretty obviously ideological otherwise. Which is fine, but we shouldn’t pretend otherwise be…

I think it's perfectly rational to take a wait-and-see approach when a dependency has been completely rewritten from scratch. That would still be rational if it had been rewritten by hand, and not by an LLM.

This isn't a wait and see approach, this is proactively removing it

Re: Bun support is now limited and deprecated

#396
post #12

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

They support Windows, which is many millions of lines of code not written by the current maintainers.

Re: Bun support is now limited and deprecated

#397

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.

Bun was just one of multiple JS runtimes supported, so dropping them doesn't have user-facing consequences. The people posting militant comments here and harassing the maintainer on GitHub are fighting for Anthropic instead of trying to raise any legitimate concerns about yt-dlp.

Re: Bun support is now limited and deprecated

#398
post #389
post #223

Earlier quoted context omitted.

Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.

I didn't say you were irrational or a jerk. But this also isn't a fair comparison. The article doesn't say "let's wait 6 months", it says they are fully deprecating Bun. Those are two very different statements. I would have had no issue with the first. And FWIW I think my viewpoint is the uncommon one. Look at all the responses to a previous thread about it [1] and see how many of them are negative. It's certainly a…

I don't know if your viewpoint is uncommon or if the vibe-coding hating crowd is just louder.

Re: Bun support is now limited and deprecated

#399
post #191

Earlier quoted context omitted.

That's not what I meant by political. I meant political in the more modern sense of "appealing to emotion rather than thought". EDIT: Everyone is rightfully calling me out that this doesn't make a lot of sense. What I meant is that the move is driven by ideology. I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion. But it's fair enough to c…

That has nothing to do with what "politics" means but it's exactly how people have started using "political" to mean "idea I don't agree with".

In software engineering the word has also long meant "a decision not made purely on technical terms"

Re: Bun support is now limited and deprecated

#400

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…

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. Studies suggest you aren't any faster and may in fact be slower. It's difficult to study such a new tech, but even optimistically, empirical evidence is only showing a ~3% gain in some domains. Writing code is rarely the limiting factor in our work.

I think those studies have framing or methodological issue.

I agree the maintenance burden is probably being undervalued by developers in general, but there's just no way the work I do isn't faster. I just categorically couldn't have achieved the outputs I do now in the time windows I have. The software just wouldn't have existed in the world of 3 years ago and I did enough coding back then to say that with certainty.

Post reply on HN