4 ms·

Adding support again later is cheap. Stopping maintaining and testing support for upcoming versions is cheaper than doing that work. Sure it’s political but i

by fmbb 5mo ago

Adding support again later is cheap. Stopping maintaining and testing support for upcoming versions is cheaper than doing that work. Sure it’s political but it is also just a sane approach, to stay away from such disruptive change and treat it as wait-and-see instead of tagging along for the ride. There is not really any technical upside to tagging along and promising support.

dmix 5mo ago
> 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 5mo ago
  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- 5mo ago
    This isn't a wait and see approach, this is proactively removing it
    - aragilar 5mo ago
      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- 5mo ago
        Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?
        soraminazuki 5mo ago
        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- 5mo ago
        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.
        soraminazuki 5mo ago
        "Who did they mislead? They just changed their minds a few days later and words aren't what you think they mean. Here's the team's PR statement containing assertions about the 1M lines of code they never reviewed." It's unfortunate that this is what some call "engineering" while labeling actual science and engineering as "politics." yt-dlp is under no obligation to keep using a dependency from vendors that instantly flip flop and re-frame their own words and actions. That's what actual due diligence and responsible engineering looks like.
    - fmbb 5mo ago
      Proactively removing work, yes.
- fmbb 5mo ago
  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.

by fmbb 5mo ago

dmix 5mo ago

> 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 5mo ago
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- 5mo ago
  This isn't a wait and see approach, this is proactively removing it
  - aragilar 5mo ago
    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- 5mo ago
      Has the team announced that they're breaking backwards compatibility, or that testing will be reduced?
      - soraminazuki 5mo ago
        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- 5mo ago
        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.
        soraminazuki 5mo ago
        "Who did they mislead? They just changed their minds a few days later and words aren't what you think they mean. Here's the team's PR statement containing assertions about the 1M lines of code they never reviewed." It's unfortunate that this is what some call "engineering" while labeling actual science and engineering as "politics." yt-dlp is under no obligation to keep using a dependency from vendors that instantly flip flop and re-frame their own words and actions. That's what actual due diligence and responsible engineering looks like.
  - fmbb 5mo ago
    Proactively removing work, yes.
fmbb 5mo ago
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.