What is the reason?

I am not aure either, but bun wasn't using normal zig and there was drama about upstreaming. Combine that with anthropics desire to show they can help rewrite everything in rust and that probably accounts for some of it.

The explicitly stated reason is that they ran into too many segfaults and it was slowing down development velocity.

That said, I hope that Zig posts won't be plagued by "but the bun thing" like this in the near future.

> rein in? You don't like going to space? What do you have against progress?

Rein in their margins is probably a better term. I’m a spacex fan but I’m reminded of what happens to every darling leader that crushes competition. It gets complacent, uses shitty tricks to cut out competitors, and raises prices.

I saw this at Google and it’s what will happen to SpaceX (already starting with Starlink pricing) if there isn’t someone to keep the competitive pressure on.

I have a lot against its owner, who has been enabling a corrupt administration and boosting outright supremacists on social media. Not to the corrupt action of the fast track listing and the voting structure of SpaceX. And the fraudulent acquisition of xai and x that is basically taking from SpaceX to pay off other investors

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.

They used to have good limits that lasted hours, now I wiped mine in a couple of minutes..

My general understanding of the concenus on most models these days is that people consider google models to be some of the worst at tool calling, so certainly an interesting choice. Did you do any evals on this?

Performance? Second only to rust and other lower level langs. Surely you don't need this spelled out for you...

Not just performance, but static typing and prevalent in the training data/easy for LLMs to reason about.

Of course, your response admits, "second to Rust", which I am guessing is an unspoken question in the grandparent's mind.

Java and C# are there and faster.

Yes, but kids these days only consider JS, Python, Rust and Go.

If performance is the main difference, whatever that means, then basically Go should be reserved for when Rust and other lower level langs cannot be used due to some other constraint? Are we mainly talking about performant Web backends?

Say I am building some app that I know will be CPU-bound, why choose Go over say... Swift?

> why choose Go over say... Swift?

Language religious wars are silly: you should choose a language based on your constraints and personal tastes. If there's no clear advantage of one language over another for a given task - then all the options are viable, pick one and get on with solving the problem.

>If performance is the main difference, whatever that means, then basically Go should be reserved for when Rust and other lower level langs cannot be used due to some other constraint?

Or when performance is the main but not the only difference, and there are many other benefits.

>Say I am building some app that I know will be CPU-bound, why choose Go over say... Swift?

Because unless you're building for macOS/iOS, Swift is really a no-go, with lackluster support for other platforms. Plus slow to build and convoluted.

Even if it did, its OSS now, open a PR! :P Note: It's not actually the same app, just a clone/reproduction so it's built from scratch essentially.

Does that include released moon landing statements from astronauts 50+ years ago?

ok I said these days, which includes the gutting of major instutitions and departments. not 50+ years ago, when things were still relatively sane and verifiable.

these days.

Hey everyone, look at the luddite.