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.
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.
I like rate-limiting. I know none of my users will need more than 10qps. I set that for all routes, and all bots get throttled. I can also have much higher rate-limit for authenticated users. Have not had bots slamming me - they just get 429s
Vue3 is great. Also Svelte5. But I’m not sure I would use either of those for an email. And sometimes you don’t need any interactivity in the frontend and server-side-rendered HTML can be a good option.
I don't see why there wouldn't be, it's cheaper to manufacture with seemingly no downsides. They probably won't revise the 4GB and 8GB versions until their stocks of the original stepping are used up though, and once they do introduce revised versions it may be a lottery which version you get for a while.
I'll bet they just slipstream them in. There was a huge backlog of the 8GB, that now looks pretty much cleared out. So it could be awhile before the D0 show up.
TSMC charged just a hair under $4000 per 16nm wafer in 2020.
Wafer calculators at 0.2 defect/cm2 on a 300mm wafer gives 950 fully-good dies out of 1061 for the old die (~89% good) and 1469 fully-good dies out of 1584 (~93%) for the new dies.
Dividing that out gives $4.21/chip for the old chip and $2.72/chip for the new chip. At $80 for an 8gb board, that represents a ~1.9% increase in profit per board. For the $60 4gb version, it's more like 2.5% increase in profit per board.
In real-world terms, if they sell 10M Pi5 units with the new chip, they'll have an extra $15M in the bank in saved production costs alone (minus whatever costs to strip everything out and tape out again). Furthermore, the new chip gets cheaper with every chip they make as the R&D costs get more and more diluted.
