Hacker News Reader

Comment by GGO | Hacker News Reader

If you wait for more segfaults, OOMs and other issues, than you have failed to avoid the problem. In my opinion this direction is correct and history will show who's right.

View on HN

When expressed, sounds like a trivial principle. It's surprising how rare it is to see people actually do this. Not only with tech stack: choosing cars, laptops, staying in a toxic relation, the list goes on

Notably, they aren't (yet) dropping support for older, pre-rewrite versions of Bun. They also could be leaving the door open to support Bun in the future, if the rewrite proves successful. I think waiting and seeing is the right, conservative move.

If that was how it was phrased I think there would have been less push back, but that's not at all how it's been communicated. There is no assumption to rereview at a later date at all given the focus on the AI usage etc.

If they said we will rereview in 1-6 months or whatever the whole discussion would be mute.

Why should yt-dlp commit to review their decision in the future about a project that makes no commitment (that I've seen) on reviewing their source code?

I get the idea to "battle-test" the rewrite first but (a) how does one even determine a reasonable timeframe for battle-testing that much LOC and (b) each vibe-coded update pushed to the Bun upstream basically resets the battle-testing timer. I guess you could lag behind $LATEST by a given window but that just brings us back to (a).

Given that part of their announcement is to keep supporting pre-rewrite versions of Bun, it implies to me that they are open to reconsider if the Bun team cleans up their act. I don't think it could get any more reasonable than that.

There’s no discussion and they don’t owe you any assumptions.

Bun shat on community and yet-dlp owed them free testing? No, sir.

Reply on news.ycombinator.com