11 ms·

This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed m

by johnfn 5mo ago

This decision seems to based more in politics than engineering. Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) It seems that you are making this decision because you get a bad feeling when thinking about AI involvement. I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here.

leobuskin 5mo ago
absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid
- cizezsy 5mo ago
  What are you afraid of?
  - nish__ 5mo ago
    A codebase that no human understands.
  - leobuskin 5mo ago
    I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs, if the maintainer takes responsibility, and in projects like Bun it happens "by default", I think.
    - desecratedbody 5mo ago
      [dead]
    - cizezsy 5mo ago
      I agree with you that AI-written code should not be a problem and tons of open-source projects have AI-written code right now. But do you really believe the way Bun rewrites and merges its code to master is the same as before? The change in rhetoric (from "don't overreact, it's just an experiment" to "merge it anyway"), the never-arrived blog post promised to explain the decision are concerning to me. I really appreciate the maintainers' effort towards this awesome project. However, I think it is fair to be a little bit less confident with the current state of Bun.
- bhaak 5mo ago
  The whole code base is a vibe coded rewrite, half a year after Bun was acquired by Anthropic. I see lots of ground for that claim.
  - doug_durham 5mo ago
    There is no evidence that it was "vibe" coded. It was ported to Rust by an expert engineer using an AI tool using solid SWE practices.
    - 1attice 5mo ago
      That's just agreeing with extra steps.
    - vor_ 5mo ago
      In 7 days?
    - b40d-48b2-979e 5mo ago
      Those SWE practices were so solid that the rewrite was already rolled back!
    - cheesefck 5mo ago
      the speed of the rewrite and various analyses of the resultant codebase provide ample evidence that it was vibe coded and solid SWE practices were ignored nobody understands the Bun Rust codebase. I wouldn't risk my business on code understood by no person. who is responsible? who will take accountability? nobody. into the trash with it.
    - oytis 5mo ago
      How can you claim following SWE best practices if couldn't realistically even have read the code?
      - shimman 5mo ago
        "Please follow best practices." You're telling me that isn't good enough? You might need to head off to the VC reeducation camps.
lynndotpy 5mo ago
Every decision is made with imperfect information about the tool, its future, and your current/future needs. This is a normal type of engineering decision. Bun being replaced entirely with stochastically generated code is red flag (regardless of whether it was or not). But Bun was also acquired by a huge corporation, which has been classically a huge red flag. Both of these are plenty of reason for yt-dlp not to support Bun. In either case, this seems like a niche use case. I've used yt-dlp for years and I've never used Bun with it. If Anthropic really wants their recent acquisition to be supported in yt-dlp, it can fork it and support it itself.
GGO 5mo ago
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.
- aljgz 5mo ago
  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
- tomjakubowski 5mo ago
  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.
  - pylotlight 5mo ago
    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.
    - yallpendantools 5mo ago
      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.
hnav 5mo ago
a vibecoded rewrite right after being acquired is not political?
- raincole 5mo ago
  No one says that? Of course Bun rewrite is political. And if you deprecate Bun support due to they did something political, obviously this decision itself is political too.
- johnfn 5mo ago
  Is it so unthinkable to people on "hacker" news that someone might want to try a cool experiment like rewriting an entire repo into Rust?
  - deleted 5mo ago
    [deleted]
  - guilhas 5mo ago
    Cool experiment? true Cool production? false
  - ozozozd 5mo ago
    Is it so unthinkable that people don’t want to participate in that cool experiment?
  - ChoGGi 5mo ago
    Most commenters here don't have an issue with Rust. The 1M lines of code refactor by AI in a week or so then thrown into a production codebase... Yeah
827a 5mo ago
You may not want to take part in politics, but politics wants to take a part in you.
gpm 5mo ago
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to experiment on your users if you thought there was a reasonable probability of increased security vulnerabilities. I think there's a good argument that the responsible thing to say would be "we aren't going to immediately support running our software on a new bun release cut from main right now". It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.
- johnfn 5mo ago
  > It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything. I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable engineering decision. Saying "because they vibe coded we are dropping support for Bun" sounds political.
  - 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
827a 5mo ago
FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.
- johnfn 5mo ago
  Can you link me a source that says that the rewrite shipped to a point release (not canary)? I'm not seeing this.
- deleted 5mo ago
  [deleted]
- gilrain 5mo ago
  News to me… share a link?
- raincole 5mo ago
  The whole point of having canary builds is that they're unstable. That's why they're called canary. Rockets failing in test flights isn't a bad thing.
  - Shank 5mo ago
    > Rockets failing in test flights isn't a bad thing. I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.
    - raincole 5mo ago
      Yes, building rockets costs money and is bad for environments.
    - haaz 5mo ago
      Yes, exactly this. SpaceX are super environmentally irresponsible, I wish they would follow the ESA/NASA development model that is so much better for the environment! So European.
hypeatei 5mo ago
I believe you contradicted your first point by following it with "If Bun starts having more bugs and feeling like worse software" ...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on. As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your code still works and no effects show up at runtime. Are you going to keep using it or dump it based on the "feeling" that something isn't right?
- johnfn 5mo ago
  Bug counts are numbers. Memory usage and performance are numbers. Eventually those numbers get so bad that you leave.
  - fmbb 5mo ago
    Well if you promise support you promise support. You cannot take back a promise after you make it. So if you discover bugs later you cannot just leave. This script is just a JavaScript helper to bring full YouTube support to some media download tool. It does not seem important to anyone that executing it using Bun is supported. They support the Deno and Node runtimes.
fdsajfkldsfklds 5mo ago
A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.
- johnfn 5mo ago
  But what exactly are you projecting? Typically when people have said they have a bad feeling about something (imagine Next.js) it's because they are running into more bugs or they are seeing more production incidents. In this case there has been no chance to observe these things.
  - fdsajfkldsfklds 5mo ago
    Engineering decisions and the resulting output. We've known for decades that machine-translated code is garbage, and should only be done as a last resort.
    - hathawsh 5mo ago
      Your HN account is too new for me to be sure whether you're being sarcastic or not. Perhaps you know, or perhaps you don't, that all code is machine-translated, even assembly language. None of it is perfect, but it's not garbage. Today's AI merely provides a new level. It's a weird, non-deterministic level, but hiring an employee to write code for you is similarly non-deterministic.
      - fdsajfkldsfklds 5mo ago
        Right, and that's why Mel was a true programmer! Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.
cizezsy 5mo ago
I don't think refactoring 1M lines of code into another language within 7 days and merging it to master is responsible. I won't make my code depend on it.
- egorfine 5mo ago
  It's not refactoring. It's LLM transpiled.
  - ozozozd 5mo ago
    I think the correct term is *translopped*
  - cheesefck 5mo ago
    [dead]
  - glouwbug 5mo ago
    Sometimes programs work because they rely on undefined behaviour. The users validate that. A famous quote: “we don’t break user space”
    - egorfine 5mo ago
      This quote comes from an old guy who can't seem to grasp the AI revolution and is manually programming some obscure shit in a language for old people.
      - glouwbug 4mo ago
        You're literally able to write this because of all the obscure shit
        egorfine 4mo ago
        sarcasm I am one of the old guys myself lol
deleted 5mo ago
[deleted]
king_geedorah 5mo ago
“... it seems unlikely he would ship this rewrite if it didn’t meet his quality bar” is every bit as vibes-based as the decision you are critiquing.
- johnfn 5mo ago
  Jared has shipped a lot of things that have impressed me. His software is measurably faster than the alternatives, and I have measured it. It runs code that Node et al can't run, and I have tried. These are normal, everyday experiences with software - based in fact, not vibes. I'm not going to argue every decision he's ever made is amazing, but his decisions have historically tracked above average.
  - dogleash 5mo ago
    So, you're fanboying? If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.
    - johnfn 5mo ago
      Stating e.g. "Bun is more performant than Node [along a particular benchmark]" is not a fanboy statement. It's a statement of measurable fact.
      - deleted 5mo ago
        [deleted]
  - n_e 5mo ago
    > It runs code that Node et al can't run What kind of code can't node run?
    - johnfn 5mo ago
      Bun supports import and require together in the same file https://bun.com/docs/runtime/module-resolution#using-import-and-require-together https://bun.com/docs/runtime/module-resolution#using-import-...
apalmer 5mo ago
It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.
- johnfn 5mo ago
  I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.
  - omnimus 5mo ago
    It's not less reasonable. They don't have to promise giving Bun time in the future to evaluate. They might do it but they absolutely don't have to be responsible for doing it when the project made such dramatic shift. They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.
    - johnfn 5mo ago
      They can absolutely do what they want, and I can absolutely say it's an unreasonable decision. When I say "unreasonable", I am evaluating whether they are operating on sound technical principles or not - not like, "are they allowed to do this" or something more obviously true.
  - tatjam 5mo ago
nesarkvechnep 5mo ago
Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.
- gpm 5mo ago
  > They couldn't upstream their vibe coded "improvements" What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.
  - deleted 5mo ago
    [deleted]
  - soledades 5mo ago
    they're referring to the changes they tried to upstream to zig.
    - tomjakubowski 5mo ago
      To be fair, I don't know if the Bun team ever did try to upstream it. In their Twitter thread announcing their vibe-coded fork of the Zig compiler, they said they wouldn't bother trying to upstream their changes because of Zig's policy banning LLM-authored contributions. Still probably a calculated political move to cut ties with Zig and muster community support for a Rust rewrite. https://x.com/bunjavascript/status/2048428104893542781 https://x.com/bunjavascript/status/2048428104893542781
      - happymellon 5mo ago
        They did try upstreaming to Zig, but it was rejected for already being implemented not because it was vide coded. https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19?u=andrewrk https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... Bun were so excited about their 4x speed improvement that they missed that Zig had already implemented it, plus other optimisations that were far larger.
negura 5mo ago
> This decision seems to based more in politics than engineering. I'm glad some engineers realize that technology is inseparable from politics. It always has been. All evil came from engineers who beleived they were above politics. Selecting the tool which got the job done/made the number go up/paid a paycheck is how we got Facebook, Google, Palantir, crypto, AI, techno-fascism and neo-feudalism. None of it would've have happened without engineers blindly applying their knowledge to achieve "purely" technical results, while ignoring the social consequences. With the hindsight of the last 20 years, anyone who still advocates for an irresponsible adoption of technology should be considered automatically suspect
rileymichael 5mo ago
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks
baublet 5mo ago
Yeah this is a cringe way to weigh in on something completely unrelated to your project. Who cares if some random package supports Bun? Compat was always on Bun, anyway.
- cybercatgurrl 5mo ago
  it’s a way to win supporters and make noise. everyone is taking sides
burnte 5mo ago
> This decision seems to based more in politics than engineering. You are 100% right. This is a decision made on VIBES and not evidence. The proof is here: > Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid. They haven't tested it, they haven't found a single problem. They just don't like AI code and they're clearly saying "the fact that the project tested every line of code and it passes all tests doesn't matter to us. The fact that it's vide coded by people who literally make coding LLMs also doesn't matter." Pure ego, no data.
- guilhas 5mo ago
  So a vibed decision to reject vibed code. Minus minus equals plus?
  - burnte 5mo ago
    I think you should read what the bun devs published about their process. It's not just vibed.
    - guilhas 5mo ago
      Care to share a link? There are 0 posts on Bun blog, or the GitHub page README announcing/explaining the rational for the rewrite, or project direction
      - burnte 5mo ago
        https://news.ycombinator.com/item?id=48073680 https://news.ycombinator.com/item?id=48073680 There's been lots of talk about it here and on his twitter and such.
        guilhas 5mo ago
        Vibes code and social media talk just how I like my projects
deleted 5mo ago
[deleted]
blks 5mo ago
Anyone who merges such a huge PR of ai generated code doesn’t deserve trust. This is a real black box now, even for the developer himself.
- glouwbug 5mo ago
  This is a good example of what many private companies are doing, and the rude awakening they’re in for with token price hikes and vendor lock in. It’s like Oracle all over again
Robdel12 5mo ago
I have no idea how that’s what you get from this. I don’t want my project using any tech that decides to take 6 days to rewrite the entire library with AI. That is at its core an engineering decision. No healthy engineering team is going to do that. And I’d want to distance myself as far as I could from a project that behaves like that.
the_gipsy 5mo ago
Why wait? Seems reasonable to preemptively drop support and let someone else either suffer the fallout, or get proven wrong and just pick up support again. It's not for a lack of people motivated by IA. Unless the motivation is more "use my IA generated content" than "actually consume IA generated content", of course.
guilhas 5mo ago
Isn't that what Bun/Anthropic did? A rewrite based on vibes? Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse All Bun devs are happy to change programming language? When their competition is already in rust and more mature While using the LLM that is now paying their salaries. Kind of a conflict of interest Even a major version upgrade is enough for me not to touch it for 6 months, let alone a full rewrite Has Bun posted any analysis and shown the data?
- egorfine 5mo ago
  > Has Bun posted any analysis and shown the data? Jarred promised a blog post just like he promised to not merge the slop branch.
t_mahmood 5mo ago
So, let's see here. Here we have a program, that is used to install scripts from source that has been targeted, and breached multiple times last few months, can run arbitrary code on millions or billions of user computer, servers. And, it was ported to another programming language, resulting in 1m LOC, in 7 days for publicity stunt of a LLM company Even multiple people can not go through 1m lines of code for any kind of vulnerability in 7 days, let alone 'observe' more segfaults, OOMS, unsafe behavior, on who knows how many possible ways things can go wrong in this new condition. Only guaranty is 99% tests passed, and the engineer who is paid by the same LLM company. How in the world, any sane engineer would agree, this would be remotely a good idea to continue using this tool, for a chance that such a expensive change won't actually land in production?
throwaw12 5mo ago
> I don't select my engineering tools because they give me a bad feeling I do, for example when I see constant behavior of lying, or negligence for security issues or not considering valid PRs and rewriting it to fit their paid plan and so on. > I select them because they do the thing I want them to. This is one of the dimensions when I pick the tools, I know Oracle produces nice products, but I don't want to get sued if I do something accidentally their lawyers dislike.
627467 5mo ago
> I will base that on data -- not a feeling I have. and yet... > If Bun starts having more bugs and feeling like worse software, I'll stop using it. Is it not possible to judge that certain approach is more likely to bring unforseen controlable problems than another by analyzing how it works without assessing it's output? No "feeling" is needed
htrp 5mo ago
>I don't select my engineering tools because they give me a bad feeling But you do select your engineering tools on faith apparently.
kqp 5mo ago
Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.
- atonse 5mo ago
  YOLO? Bun has an extensive test suite and this implementation passed the test suite. Can we at least try to be a bit more accurate and less hyperbolic? I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others. I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.
  - truncate 5mo ago
    >> same people that made bun have made this decision Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.
    - atonse 5mo ago
      You can go read all the details on Jarred's X account - including the progress, how it was thought out, strategy, that they're aware that it looks like zig still, etc etc etc. Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to man. Suffice to say, I'm yet to see anything that really worries me in any major way with this.
      - truncate 5mo ago
        I've read the details, strategy, extensive test suite etc. I'm sorry, I don't think "they have access to Claude Mythos" is the rationale to it unless you truly believe the marketing 100%. I think we'll just see how it all turns out. Maybe check back in a year or two on hwo it all goes. Anyone who says they "know" or are "very sure" this is the right path or wrong path is plain stupid IMO. Having seen how things work in big companies with high market visibility, I believe there is non-trivial chance this driven mostly as marketting stunt (particularly in current climate) and decision isn't purely based on best interest of Bun's future and longevity.
jmull 5mo ago
Not sure what seems "political" about this. When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not. You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost. There are a lot of unknowns about vibe bun right now. One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out. If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.
jameson 5mo ago
> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) Your argument could go other way too. Why haven't they landed if they're so confident with the change?
teaearlgraycold 5mo ago
The rust rewrite isn’t even out of canary IIUC.
- jdiff 5mo ago
  A merge to main itself is pretty substantial, especially a week after saying, "[This] code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely."
conartist6 5mo ago
I wouldn't call it politics. I've seen enough people aim a gun at their foot and pull the trigger. They'll never thank you for stopping them, they just want to be left alone while they do it. So, great, if this dude wants to regress through the workforce to a level of engineering maturity I associate with a high school student, I don't wish to try to be the one to stop him. Doesn't mean I'm gonna follow him. It's possible to be smart enough to just not walk into the tarpit. He's going in, I'm not.
ozgrakkurt 5mo ago
> I select them because they do the thing I want them to. Regardless of the other aspects, this is a joke in any context I have been in since I started working in this field about 9 years ago. Even as pure logic, you know they do what you want it to do only after you chose them. You can’t possibly be trying every option to the fullest capacity of your application. You also converge on the “Jarred” aspect and the guy that made the decision in the title post has the opposite sentiment
brailsafe 5mo ago
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to Among tools that meet a technical expectation—especially for (often) superfluous activities like downloading videos—I pick one that feels right and costs the right amount, and that's the one that wins. Free + works + usable is an unbeatable combination. However, I'd argue their decision is related to a peer dependency than it is itself one about an engineering tool, which is an assessment of the risk surface and potential cost associated with doing so. I already wasn't using bun at all, but if they stopped supporting whichever runtime I do use, I can either adapt or stop using yt-dlp, which I won't because this isn't a technical thing worth wasting much time on. This mild, recent change to recently introduced peer dependency integration is largely inconsequential, and I support the call to not waste time providing extra support if it hypothetically became necessary.
elsonrodriguez 5mo ago
> I don't select my engineering tools because they give me a bad feeling. Those bad feelings are often your years of experience trying to tell you something.
scuff3d 5mo ago
As far as I'm concerned Bun has been extremely irresponsible with this entire rewrite, and it calls into question their entire development philosophy. Any project that cares about stability and reliability should steer clear of Bun for a while.
ChoGGi 5mo ago
Everything is politics, sorry to say. Even software engineering try as we might. > feeling like worse software Politics ;)
isityettime 5mo ago
What world do you live in where selecting your dependencies doesn't involve personal judgment calls?
- johnfn 5mo ago
  Those judgement calls are driven by things like “oh this is too slow” or “oh this API is a mess”.
toaste_ 5mo ago
Reading and understanding code is more difficult than writing code. It is significantly easier to modify code that you personally wrote, or code that you have read and understood to fix an issue in previously. This is why the maintainers of a project change slowly over time and it takes a long time for new ones to get up to speed. All of Bun has been rewritten by a tool. In a different language that maintainers may not be fully proficient in. Even though the rewrite was done well, and even if we assume it's functionally equivalent to the old Zig code, there will still be future issues. And ALl of the maintainers are essentially now new hires who have never seen that code in their lives. It's not "politics" to have an ounce of sense to foresee problems in such a project as a dependency.
adverbly 5mo ago
> it seems unlikely he would ship this rewrite if it didn't meet his quality bar What happened to > don't select my engineering tools because they give me a bad feeling Who cares if you have a good feeling about this dude? There are obvious and clear conflicts of interest at play here. If you care at all about quality, you'll wait before adopting new releases until bugs get discovered/ironed out. Don't adopt based on some dude's reputation when that reputation was built under a very different incentive environment.
gorgoiler 5mo ago
You can’t really tell if you got sick from dirty hands, a week old egg, or the cheeseburger you had for lunch, but if Shake Shack had also just announced they’ve moved over to vibe-cleaning their kitchens then it’s reasonable to only eat at Five Guys from now on. Let someone else iron out the kinks.
stein1946 5mo ago
> This decision seems to based more in politics than engineering. Project governance is very important on a project; the fact that Bun's authors bent the knee to their new owner shows where their priorities lie. > Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? I - them - are not going to sit around waiting for bugs to start crashing everything > I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to Good thing that you don't run an open source project then, I would remove anyone's project from my dependencies who thinks like that.
- kentm 5mo ago
  It really is amazing to me how many developers do not understand that governance is important. If I have a dependency and a maintainer of that dependency has a process I can’t trust, it’s perfectly valid to remove that dependency based on that lack of trust. Not caring about governance is how we end up with repeated supply chain attacks.
inatreecrown2 5mo ago
The first sentence on the linked page is literally: "Due to foreseeable compatibility and security issues"
feelamee 5mo ago
> This decision seems to based more in politics than engineering. Will you use untrustworthy dependencies in your project, which has users? I think, no. I don't know, but I feel that this is the case with yt-dlp. And this is absolutely engineering - care about quality and security of your software, which is used by thousands of people
allthetime 5mo ago
the bun team has recently demonstrated a lack of agency over their project. making massive structural changes with unclear and misleading communication. There is nothing political about seeing that as a red flag and deciding to rely on more stable projects.
felipellrocha 5mo ago
I would argue the opposite. The decision to rewrite was based on politics, and the decision to deprecate support was based on actual engineering.
boomlinde 5mo ago
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. With that in mind, is there anything that yt-dlp uses the Bun runtime for which it can not use the other supported runtimes for? Similarly, perhaps the yt-dlp maintainers shouldn't keep supporting Bun just because it gives them a good feeling when every runtime incurs a maintenance cost. That said, as a developer I skim over so much bullshit simply based on "bad feelings". I don't have time to evaluate every potentially useful technology in terms of whether it does what I want it to do, and no one else does either. It's clear to me that Bun is in an experimental phase of development and I think that's a good enough reason to move on if your use case is not.
soraminazuki 5mo ago
Every accusation is an admission, isn't it? As always with these cases, the rhetorical contrast is staggering compared to the thread about Bun deprecating Zig. Bun made a snap decision to merge 1M lines of unreviewed code within a week, including code generated moments before the merge. AI or not, that forces downstream users to cope with total unpredictability. This process bears no resemblance to science or engineering. All the QA work you're demanding of yt-dlp is work Bun should've done. Trying to flip that responsibility proves your argument isn't grounded in engineering principles. And you sure made your feelings known in your comments for someone who claims not to let emotions affect technical decisions. yt-dlp made a sane technical decision to drop a high-risk dependency. Not only is the Bun code now unpredictable, but the maintainer is too. The maintainer called the rewrite "experimental," then merged it within a week. If direct statements can flip overnight without warning or explanation, it's no wonder downstream projects want out. Especially when yt-dlp already supports alternative JS runtimes.
watwut 5mo ago
It is entirely rational to not use a completely new library no one yet confirmed is good. And complete agentic rewrite makes it completely new thing. The argument that you somehow cant unless you go through trouble of testing it is way more "politics" and way less "engineering".
wiseowise 5mo ago
> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here. I have a t-shirt signed by THE Jarred himself, how much are you willing to pay for it? Comes with a month of free Claude max subscription.

by johnfn 5mo ago

leobuskin 5mo ago

absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid

cizezsy 5mo ago
What are you afraid of?
- nish__ 5mo ago
  A codebase that no human understands.
- leobuskin 5mo ago
  I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs, if the maintainer takes responsibility, and in projects like Bun it happens "by default", I think.
  - desecratedbody 5mo ago
    [dead]
  - cizezsy 5mo ago
    I agree with you that AI-written code should not be a problem and tons of open-source projects have AI-written code right now. But do you really believe the way Bun rewrites and merges its code to master is the same as before? The change in rhetoric (from "don't overreact, it's just an experiment" to "merge it anyway"), the never-arrived blog post promised to explain the decision are concerning to me. I really appreciate the maintainers' effort towards this awesome project. However, I think it is fair to be a little bit less confident with the current state of Bun.
bhaak 5mo ago
The whole code base is a vibe coded rewrite, half a year after Bun was acquired by Anthropic. I see lots of ground for that claim.
- doug_durham 5mo ago
  There is no evidence that it was "vibe" coded. It was ported to Rust by an expert engineer using an AI tool using solid SWE practices.
  - 1attice 5mo ago
    That's just agreeing with extra steps.
  - vor_ 5mo ago
    In 7 days?
  - b40d-48b2-979e 5mo ago
    Those SWE practices were so solid that the rewrite was already rolled back!
  - cheesefck 5mo ago
    the speed of the rewrite and various analyses of the resultant codebase provide ample evidence that it was vibe coded and solid SWE practices were ignored nobody understands the Bun Rust codebase. I wouldn't risk my business on code understood by no person. who is responsible? who will take accountability? nobody. into the trash with it.
  - oytis 5mo ago
    How can you claim following SWE best practices if couldn't realistically even have read the code?
    - shimman 5mo ago
      "Please follow best practices." You're telling me that isn't good enough? You might need to head off to the VC reeducation camps.

lynndotpy 5mo ago

Every decision is made with imperfect information about the tool, its future, and your current/future needs. This is a normal type of engineering decision. Bun being replaced entirely with stochastically generated code is red flag (regardless of whether it was or not). But Bun was also acquired by a huge corporation, which has been classically a huge red flag. Both of these are plenty of reason for yt-dlp not to support Bun. In either case, this seems like a niche use case. I've used yt-dlp for years and I've never used Bun with it. If Anthropic really wants their recent acquisition to be supported in yt-dlp, it can fork it and support it itself.

GGO 5mo ago

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.

aljgz 5mo ago
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
tomjakubowski 5mo ago
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.
- pylotlight 5mo ago
  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.
  - yallpendantools 5mo ago
    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.

hnav 5mo ago

a vibecoded rewrite right after being acquired is not political?

raincole 5mo ago
No one says that? Of course Bun rewrite is political. And if you deprecate Bun support due to they did something political, obviously this decision itself is political too.
johnfn 5mo ago
Is it so unthinkable to people on "hacker" news that someone might want to try a cool experiment like rewriting an entire repo into Rust?
- deleted 5mo ago
  [deleted]
- guilhas 5mo ago
  Cool experiment? true Cool production? false
- ozozozd 5mo ago
  Is it so unthinkable that people don’t want to participate in that cool experiment?
- ChoGGi 5mo ago
  Most commenters here don't have an issue with Rust. The 1M lines of code refactor by AI in a week or so then thrown into a production codebase... Yeah

827a 5mo ago

You may not want to take part in politics, but politics wants to take a part in you.

gpm 5mo ago

> Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? (Of course you haven't, the rewrite hasn't even landed yet.) On the flip side it's not on the yt-dlp authors to test Bun's new development process and see if it results in more segfaults, OOMs, security vulnerabilities, etc. In fact it would arguably be negligent to experiment on your users if you thought there was a reasonable probability of increased security vulnerabilities. I think there's a good argument that the responsible thing to say would be "we aren't going to immediately support running our software on a new bun release cut from main right now". It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything.

johnfn 5mo ago
> It seems a bit unfortunate to me that they've apparently already intending to never support future releases instead of planning on re-evaluating in the future. On the other hand the yt-dlp developers definitely don't owe anyone anything. I think your final comment gets at it. If they said "OK, I am skeptical, so we're going to pause on updating to see how this Rust thing plays out" -- that sounds like a reasonable engineering decision. Saying "because they vibe coded we are dropping support for Bun" sounds political.
- 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

827a 5mo ago

FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.

johnfn 5mo ago
Can you link me a source that says that the rewrite shipped to a point release (not canary)? I'm not seeing this.
deleted 5mo ago
[deleted]
gilrain 5mo ago
News to me… share a link?
raincole 5mo ago
The whole point of having canary builds is that they're unstable. That's why they're called canary. Rockets failing in test flights isn't a bad thing.
- Shank 5mo ago
  > Rockets failing in test flights isn't a bad thing. I hate to be pedantic but for a whole host of environmental reasons, they are suboptimal, and it still incinerates money to lose a rocket during a flight test.
  - raincole 5mo ago
    Yes, building rockets costs money and is bad for environments.
  - haaz 5mo ago
    Yes, exactly this. SpaceX are super environmentally irresponsible, I wish they would follow the ESA/NASA development model that is so much better for the environment! So European.

hypeatei 5mo ago

I believe you contradicted your first point by following it with "If Bun starts having more bugs and feeling like worse software" ...so you do use feelings in your calculation? To be clear, I have no problem with that and think there is some level of speculation you need to do when deciding what to rely on. As a hypothetical, pretend that Bun added obfuscated binary blobs that get executed at build time. Well, your code still works and no effects show up at runtime. Are you going to keep using it or dump it based on the "feeling" that something isn't right?

johnfn 5mo ago
Bug counts are numbers. Memory usage and performance are numbers. Eventually those numbers get so bad that you leave.
- fmbb 5mo ago
  Well if you promise support you promise support. You cannot take back a promise after you make it. So if you discover bugs later you cannot just leave. This script is just a JavaScript helper to bring full YouTube support to some media download tool. It does not seem important to anyone that executing it using Bun is supported. They support the Deno and Node runtimes.

fdsajfkldsfklds 5mo ago

A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.

johnfn 5mo ago
But what exactly are you projecting? Typically when people have said they have a bad feeling about something (imagine Next.js) it's because they are running into more bugs or they are seeing more production incidents. In this case there has been no chance to observe these things.
- fdsajfkldsfklds 5mo ago
  Engineering decisions and the resulting output. We've known for decades that machine-translated code is garbage, and should only be done as a last resort.
  - hathawsh 5mo ago
    Your HN account is too new for me to be sure whether you're being sarcastic or not. Perhaps you know, or perhaps you don't, that all code is machine-translated, even assembly language. None of it is perfect, but it's not garbage. Today's AI merely provides a new level. It's a weird, non-deterministic level, but hiring an employee to write code for you is similarly non-deterministic.
    - fdsajfkldsfklds 5mo ago
      Right, and that's why Mel was a true programmer! Seriously though, that's an overly-pedantic definition of a compiler. Broadly speaking, languages compile in a direction of decreasing abstraction. Crossing from one high-level abstraction to another is just asking for trouble, especially in this case where the target language makes very specific performance promises as long as certain abstractions are maintained.

cizezsy 5mo ago

I don't think refactoring 1M lines of code into another language within 7 days and merging it to master is responsible. I won't make my code depend on it.

egorfine 5mo ago
It's not refactoring. It's LLM transpiled.
- ozozozd 5mo ago
  I think the correct term is *translopped*
- cheesefck 5mo ago
  [dead]
- glouwbug 5mo ago
  Sometimes programs work because they rely on undefined behaviour. The users validate that. A famous quote: “we don’t break user space”
  - egorfine 5mo ago
    This quote comes from an old guy who can't seem to grasp the AI revolution and is manually programming some obscure shit in a language for old people.
    - glouwbug 4mo ago
      You're literally able to write this because of all the obscure shit
      - egorfine 4mo ago
        sarcasm I am one of the old guys myself lol

deleted 5mo ago

[deleted]

king_geedorah 5mo ago

“... it seems unlikely he would ship this rewrite if it didn’t meet his quality bar” is every bit as vibes-based as the decision you are critiquing.

johnfn 5mo ago
Jared has shipped a lot of things that have impressed me. His software is measurably faster than the alternatives, and I have measured it. It runs code that Node et al can't run, and I have tried. These are normal, everyday experiences with software - based in fact, not vibes. I'm not going to argue every decision he's ever made is amazing, but his decisions have historically tracked above average.
- dogleash 5mo ago
  So, you're fanboying? If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.
  - johnfn 5mo ago
    Stating e.g. "Bun is more performant than Node [along a particular benchmark]" is not a fanboy statement. It's a statement of measurable fact.
    - deleted 5mo ago
      [deleted]
- n_e 5mo ago
  > It runs code that Node et al can't run What kind of code can't node run?
  - johnfn 5mo ago
    Bun supports import and require together in the same file https://bun.com/docs/runtime/module-resolution#using-import-and-require-together https://bun.com/docs/runtime/module-resolution#using-import-...

apalmer 5mo ago

It's not really political. Or let me rephrase possibly yt-dl is being political. VUT the concept of 'not adopting a core dependency until it has been widely used in production for 6 months - a year.', is not a political on general. A full rewrite of 1 million loc is essentially a new runtime that has the same ABI as the previous and for many downstream consumers it's not something they are comfortable taking a production dependency on. If for sale of argument BUn was fully rewritten by hand would be the same situation. I personally think this kind of decision is pretty standard, I also personally think the Bun LLM rewrite will be of good quality overall, but I certainly would not bet my product/company on it. I want to be the one making the risky changes on my software not being forced into it by downstream deps.

johnfn 5mo ago
I think your stance is more reasonable than the one in the article, TBH. If yt-dlp said something like "We're going to wait 6 months on the Rust rewrite", that would be reasonable. But instead it says something more like we think that Bun is vibe-coded, so we don't want to use it any more. That seems less reasonable.
- omnimus 5mo ago
  It's not less reasonable. They don't have to promise giving Bun time in the future to evaluate. They might do it but they absolutely don't have to be responsible for doing it when the project made such dramatic shift. They can do absolutely what they want with their project especially when its majority decision. There can't be no doubt about that.
  - johnfn 5mo ago
    They can absolutely do what they want, and I can absolutely say it's an unreasonable decision. When I say "unreasonable", I am evaluating whether they are operating on sound technical principles or not - not like, "are they allowed to do this" or something more obviously true.
- tatjam 5mo ago

nesarkvechnep 5mo ago

Then Bun's rewrite is also political. They couldn't upstream their vibe coded "improvements" so in spite they decided to vibe a rewrite in Rust. The arguments for the rewrite were not backed by any data.

gpm 5mo ago
> They couldn't upstream their vibe coded "improvements" What are you talking about? There is no upstream rejecting contributions here. It's the original bun developers who vibe-ported it to rust and they absolutely could and did upstream their vibe coded changes because they are the upstream.
- deleted 5mo ago
  [deleted]
- soledades 5mo ago
  they're referring to the changes they tried to upstream to zig.
  - tomjakubowski 5mo ago
    To be fair, I don't know if the Bun team ever did try to upstream it. In their Twitter thread announcing their vibe-coded fork of the Zig compiler, they said they wouldn't bother trying to upstream their changes because of Zig's policy banning LLM-authored contributions. Still probably a calculated political move to cut ties with Zig and muster community support for a Rust rewrite. https://x.com/bunjavascript/status/2048428104893542781 https://x.com/bunjavascript/status/2048428104893542781
    - happymellon 5mo ago
      They did try upstreaming to Zig, but it was rejected for already being implemented not because it was vide coded. https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19?u=andrewrk https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... Bun were so excited about their 4x speed improvement that they missed that Zig had already implemented it, plus other optimisations that were far larger.

negura 5mo ago

> This decision seems to based more in politics than engineering. I'm glad some engineers realize that technology is inseparable from politics. It always has been. All evil came from engineers who beleived they were above politics. Selecting the tool which got the job done/made the number go up/paid a paycheck is how we got Facebook, Google, Palantir, crypto, AI, techno-fascism and neo-feudalism. None of it would've have happened without engineers blindly applying their knowledge to achieve "purely" technical results, while ignoring the social consequences. With the hindsight of the last 20 years, anyone who still advocates for an irresponsible adoption of technology should be considered automatically suspect

rileymichael 5mo ago

> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. being reactive is fine if you can tolerate issues. otherwise, you need to be proactive -- don't wait for the train to hit you before you move off the tracks

baublet 5mo ago

Yeah this is a cringe way to weigh in on something completely unrelated to your project. Who cares if some random package supports Bun? Compat was always on Bun, anyway.

cybercatgurrl 5mo ago
it’s a way to win supporters and make noise. everyone is taking sides

burnte 5mo ago

> This decision seems to based more in politics than engineering. You are 100% right. This is a decision made on VIBES and not evidence. The proof is here: > Bun was recently rewritten in Rust using Claude, and its development seems to have taken a turn towards being fully vibe-coded. This is alarming and disappointing for a number of reasons, and frankly it seems like a future headache that we'd prefer to avoid. They haven't tested it, they haven't found a single problem. They just don't like AI code and they're clearly saying "the fact that the project tested every line of code and it passes all tests doesn't matter to us. The fact that it's vide coded by people who literally make coding LLMs also doesn't matter." Pure ego, no data.

guilhas 5mo ago
So a vibed decision to reject vibed code. Minus minus equals plus?
- burnte 5mo ago
  I think you should read what the bun devs published about their process. It's not just vibed.
  - guilhas 5mo ago
    Care to share a link? There are 0 posts on Bun blog, or the GitHub page README announcing/explaining the rational for the rewrite, or project direction
    - burnte 5mo ago
      https://news.ycombinator.com/item?id=48073680 https://news.ycombinator.com/item?id=48073680 There's been lots of talk about it here and on his twitter and such.
      - guilhas 5mo ago
        Vibes code and social media talk just how I like my projects

deleted 5mo ago

[deleted]

blks 5mo ago

Anyone who merges such a huge PR of ai generated code doesn’t deserve trust. This is a real black box now, even for the developer himself.

glouwbug 5mo ago
This is a good example of what many private companies are doing, and the rude awakening they’re in for with token price hikes and vendor lock in. It’s like Oracle all over again

Robdel12 5mo ago

I have no idea how that’s what you get from this. I don’t want my project using any tech that decides to take 6 days to rewrite the entire library with AI. That is at its core an engineering decision. No healthy engineering team is going to do that. And I’d want to distance myself as far as I could from a project that behaves like that.

the_gipsy 5mo ago

Why wait? Seems reasonable to preemptively drop support and let someone else either suffer the fallout, or get proven wrong and just pick up support again. It's not for a lack of people motivated by IA. Unless the motivation is more "use my IA generated content" than "actually consume IA generated content", of course.

guilhas 5mo ago

Isn't that what Bun/Anthropic did? A rewrite based on vibes? Except "because we can" and the expectation that some kind of bug will be reduced and other metrics will not get worse All Bun devs are happy to change programming language? When their competition is already in rust and more mature While using the LLM that is now paying their salaries. Kind of a conflict of interest Even a major version upgrade is enough for me not to touch it for 6 months, let alone a full rewrite Has Bun posted any analysis and shown the data?

egorfine 5mo ago
> Has Bun posted any analysis and shown the data? Jarred promised a blog post just like he promised to not merge the slop branch.

t_mahmood 5mo ago

So, let's see here. Here we have a program, that is used to install scripts from source that has been targeted, and breached multiple times last few months, can run arbitrary code on millions or billions of user computer, servers. And, it was ported to another programming language, resulting in 1m LOC, in 7 days for publicity stunt of a LLM company Even multiple people can not go through 1m lines of code for any kind of vulnerability in 7 days, let alone 'observe' more segfaults, OOMS, unsafe behavior, on who knows how many possible ways things can go wrong in this new condition. Only guaranty is 99% tests passed, and the engineer who is paid by the same LLM company. How in the world, any sane engineer would agree, this would be remotely a good idea to continue using this tool, for a chance that such a expensive change won't actually land in production?

throwaw12 5mo ago

> I don't select my engineering tools because they give me a bad feeling I do, for example when I see constant behavior of lying, or negligence for security issues or not considering valid PRs and rewriting it to fit their paid plan and so on. > I select them because they do the thing I want them to. This is one of the dimensions when I pick the tools, I know Oracle produces nice products, but I don't want to get sued if I do something accidentally their lawyers dislike.

627467 5mo ago

> I will base that on data -- not a feeling I have. and yet... > If Bun starts having more bugs and feeling like worse software, I'll stop using it. Is it not possible to judge that certain approach is more likely to bring unforseen controlable problems than another by analyzing how it works without assessing it's output? No "feeling" is needed

htrp 5mo ago

>I don't select my engineering tools because they give me a bad feeling But you do select your engineering tools on faith apparently.

kqp 5mo ago

Every single macOS update the top comments are about giving it six months to stabilize, but when a program’s biggest ever rewrite involves a lot of AI, the top comment is calling you irrational if you don’t YOLO it, and probably a jerk, too.

atonse 5mo ago
YOLO? Bun has an extensive test suite and this implementation passed the test suite. Can we at least try to be a bit more accurate and less hyperbolic? I will continue to use Bun because the same people that made bun have made this decision. I trusted them one week ago. I have used bun for the past 2 years, and so have many others. I'm not about to just assume they've become immature idiots yolo'ing stuff overnight. They're still the same people they were a week ago. Or two weeks ago.
- truncate 5mo ago
  >> same people that made bun have made this decision Are they the same people though? Their interests, goals, environment, incentives, boss etc etc all changed after they got acquired by Anthropic. Its not uncommon for a big company to acquire a smaller one and completely destroy that product to serve the parent company's goal.
  - atonse 5mo ago
    You can go read all the details on Jarred's X account - including the progress, how it was thought out, strategy, that they're aware that it looks like zig still, etc etc etc. Speaking of environment though, everyone neglects to mention that the Bun core team now has access to Claude Mythos. You think they haven't already run Mythos against this? So they have private access to the best cybersecurity scanner known to man. Suffice to say, I'm yet to see anything that really worries me in any major way with this.
    - truncate 5mo ago
      I've read the details, strategy, extensive test suite etc. I'm sorry, I don't think "they have access to Claude Mythos" is the rationale to it unless you truly believe the marketing 100%. I think we'll just see how it all turns out. Maybe check back in a year or two on hwo it all goes. Anyone who says they "know" or are "very sure" this is the right path or wrong path is plain stupid IMO. Having seen how things work in big companies with high market visibility, I believe there is non-trivial chance this driven mostly as marketting stunt (particularly in current climate) and decision isn't purely based on best interest of Bun's future and longevity.

jmull 5mo ago

Not sure what seems "political" about this. When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not. You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost. There are a lot of unknowns about vibe bun right now. One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out. If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.

jameson 5mo ago

teaearlgraycold 5mo ago

The rust rewrite isn’t even out of canary IIUC.

jdiff 5mo ago
A merge to main itself is pretty substantial, especially a week after saying, "[This] code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely."

conartist6 5mo ago

I wouldn't call it politics. I've seen enough people aim a gun at their foot and pull the trigger. They'll never thank you for stopping them, they just want to be left alone while they do it. So, great, if this dude wants to regress through the workforce to a level of engineering maturity I associate with a high school student, I don't wish to try to be the one to stop him. Doesn't mean I'm gonna follow him. It's possible to be smart enough to just not walk into the tarpit. He's going in, I'm not.

ozgrakkurt 5mo ago

> I select them because they do the thing I want them to. Regardless of the other aspects, this is a joke in any context I have been in since I started working in this field about 9 years ago. Even as pure logic, you know they do what you want it to do only after you chose them. You can’t possibly be trying every option to the fullest capacity of your application. You also converge on the “Jarred” aspect and the guy that made the decision in the title post has the opposite sentiment

brailsafe 5mo ago

> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to Among tools that meet a technical expectation—especially for (often) superfluous activities like downloading videos—I pick one that feels right and costs the right amount, and that's the one that wins. Free + works + usable is an unbeatable combination. However, I'd argue their decision is related to a peer dependency than it is itself one about an engineering tool, which is an assessment of the risk surface and potential cost associated with doing so. I already wasn't using bun at all, but if they stopped supporting whichever runtime I do use, I can either adapt or stop using yt-dlp, which I won't because this isn't a technical thing worth wasting much time on. This mild, recent change to recently introduced peer dependency integration is largely inconsequential, and I support the call to not waste time providing extra support if it hypothetically became necessary.

elsonrodriguez 5mo ago

> I don't select my engineering tools because they give me a bad feeling. Those bad feelings are often your years of experience trying to tell you something.

scuff3d 5mo ago

As far as I'm concerned Bun has been extremely irresponsible with this entire rewrite, and it calls into question their entire development philosophy. Any project that cares about stability and reliability should steer clear of Bun for a while.

ChoGGi 5mo ago

Everything is politics, sorry to say. Even software engineering try as we might. > feeling like worse software Politics ;)

isityettime 5mo ago

What world do you live in where selecting your dependencies doesn't involve personal judgment calls?

johnfn 5mo ago
Those judgement calls are driven by things like “oh this is too slow” or “oh this API is a mess”.

toaste_ 5mo ago

Reading and understanding code is more difficult than writing code. It is significantly easier to modify code that you personally wrote, or code that you have read and understood to fix an issue in previously. This is why the maintainers of a project change slowly over time and it takes a long time for new ones to get up to speed. All of Bun has been rewritten by a tool. In a different language that maintainers may not be fully proficient in. Even though the rewrite was done well, and even if we assume it's functionally equivalent to the old Zig code, there will still be future issues. And ALl of the maintainers are essentially now new hires who have never seen that code in their lives. It's not "politics" to have an ounce of sense to foresee problems in such a project as a dependency.

adverbly 5mo ago

> it seems unlikely he would ship this rewrite if it didn't meet his quality bar What happened to > don't select my engineering tools because they give me a bad feeling Who cares if you have a good feeling about this dude? There are obvious and clear conflicts of interest at play here. If you care at all about quality, you'll wait before adopting new releases until bugs get discovered/ironed out. Don't adopt based on some dude's reputation when that reputation was built under a very different incentive environment.

gorgoiler 5mo ago

You can’t really tell if you got sick from dirty hands, a week old egg, or the cheeseburger you had for lunch, but if Shake Shack had also just announced they’ve moved over to vibe-cleaning their kitchens then it’s reasonable to only eat at Five Guys from now on. Let someone else iron out the kinks.

stein1946 5mo ago

> This decision seems to based more in politics than engineering. Project governance is very important on a project; the fact that Bun's authors bent the knee to their new owner shows where their priorities lie. > Have you observed Bun have more segfaults, OOMs, etc, since the Rust rewrite? Have you noticed more security vulnerabilities? Have you seen more bugs? I - them - are not going to sit around waiting for bugs to start crashing everything > I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to Good thing that you don't run an open source project then, I would remove anyone's project from my dependencies who thinks like that.

kentm 5mo ago
It really is amazing to me how many developers do not understand that governance is important. If I have a dependency and a maintainer of that dependency has a process I can’t trust, it’s perfectly valid to remove that dependency based on that lack of trust. Not caring about governance is how we end up with repeated supply chain attacks.

inatreecrown2 5mo ago

The first sentence on the linked page is literally: "Due to foreseeable compatibility and security issues"

feelamee 5mo ago

> This decision seems to based more in politics than engineering. Will you use untrustworthy dependencies in your project, which has users? I think, no. I don't know, but I feel that this is the case with yt-dlp. And this is absolutely engineering - care about quality and security of your software, which is used by thousands of people

allthetime 5mo ago

the bun team has recently demonstrated a lack of agency over their project. making massive structural changes with unclear and misleading communication. There is nothing political about seeing that as a red flag and deciding to rely on more stable projects.

felipellrocha 5mo ago

I would argue the opposite. The decision to rewrite was based on politics, and the decision to deprecate support was based on actual engineering.

boomlinde 5mo ago

> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. With that in mind, is there anything that yt-dlp uses the Bun runtime for which it can not use the other supported runtimes for? Similarly, perhaps the yt-dlp maintainers shouldn't keep supporting Bun just because it gives them a good feeling when every runtime incurs a maintenance cost. That said, as a developer I skim over so much bullshit simply based on "bad feelings". I don't have time to evaluate every potentially useful technology in terms of whether it does what I want it to do, and no one else does either. It's clear to me that Bun is in an experimental phase of development and I think that's a good enough reason to move on if your use case is not.

soraminazuki 5mo ago

Every accusation is an admission, isn't it? As always with these cases, the rhetorical contrast is staggering compared to the thread about Bun deprecating Zig. Bun made a snap decision to merge 1M lines of unreviewed code within a week, including code generated moments before the merge. AI or not, that forces downstream users to cope with total unpredictability. This process bears no resemblance to science or engineering. All the QA work you're demanding of yt-dlp is work Bun should've done. Trying to flip that responsibility proves your argument isn't grounded in engineering principles. And you sure made your feelings known in your comments for someone who claims not to let emotions affect technical decisions. yt-dlp made a sane technical decision to drop a high-risk dependency. Not only is the Bun code now unpredictable, but the maintainer is too. The maintainer called the rewrite "experimental," then merged it within a week. If direct statements can flip overnight without warning or explanation, it's no wonder downstream projects want out. Especially when yt-dlp already supports alternative JS runtimes.

watwut 5mo ago

It is entirely rational to not use a completely new library no one yet confirmed is good. And complete agentic rewrite makes it completely new thing. The argument that you somehow cant unless you go through trouble of testing it is way more "politics" and way less "engineering".

wiseowise 5mo ago

> I don't select my engineering tools because they give me a bad feeling - I select them because they do the thing I want them to. If Bun starts having more bugs and feeling like worse software, I'll stop using it. But I will base that on data -- not a feeling I have. Jarred has done a lot of impressive stuff with Bun, and it seems unlikely he would ship this rewrite if it didn't meet his quality bar - I am willing to see him out here. I have a t-shirt signed by THE Jarred himself, how much are you willing to pay for it? Comes with a month of free Claude max subscription.