[dmix]

> 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 because we might agree with it

[kelnos]

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.

[usef-]

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

[aragilar]

It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.

[usef-]

Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?

[soraminazuki]

No, the team mislead people by claiming the rewrite was experimental only to merge 1M lines of unreviewed code merely days later. Responsible software developers don't operate on blind trust, and both the Bun code and the maintainers are highly unpredictable at this point. That's more than sufficient technical grounds to drop an optional and replaceable dependency, especially since there are no user-facing consequences beyond the bruised egos of a cult following that demands blind loyalty to its tech‑bro leaders.

[usef-]

Who did they mislead? A few days later it was no longer experimental and it became the main dev branch as they decided it would be the way forward for development (see the blog post on why). No stable release has been declared yet.

Here was the Bun team's message on merge:

> It passes Bun's pre-existing test suite on all platforms (and fixes several memory leaks and flaky tests), the binary size shrinks by 3 MB - 8 MB, the benchmarks are between neutral and faster - and most importantly, we now have compiler-assisted tools for catching & preventing memory bugs, which have costed the team an enormous amount of development & debugging time over the years.

>

> The codebase is otherwise largely the same. The same architecture, the same data structures. Bun still uses few 3rd party libraries. No async rust.

[fmbb]

Proactively removing work, yes.

[fmbb]

I don’t thing maintaining and testing support for an extra runtime is free.

It is by definition cheaper to not support extra runtimes like Kaluma, Elsa, WinterJS. Adding support is not just the initial work of adapting CI and writing policies, maintenance and support is ongoing work.