Live data from Hacker News

Bun support is now limited and deprecated

github.com

361–370 of 646 posts

Re: Bun support is now limited and deprecated

#361
post #308
post #263

Earlier quoted context omitted.

Most people probably think the text editor used would have no meaningful effect on the code written. I don't think many would say the same for LLMs. Maybe vibe bun is just as good or better than old bun, but how would we know at this point? > ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology... That's not true.…

> Maybe vibe bun is just as good or better than old bun, but how would we know at this point? By considering objective facts like efficiency, performance, error rates, security vulns etc. like we always do?

Do you mind if I vibecode a fresh vehicle control software for your car?

Don’t worry, it’ll just be in a different language.

Re: Bun support is now limited and deprecated

#362
post #73

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…

> 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.

Re: Bun support is now limited and deprecated

#363

Earlier quoted context omitted.

In all sincerity, what does political even mean in this context? ELI5, I’m a toddler when it comes to the politics of AI/LLMs.

Its a polarizing world with AI. There are fanboys drinking the kool-aid blindly listening to whatever Sammy/Dario/... say as gospel, and on other side there are haters who again blindly reject the fact that these AI tools can be actually be useful. I think that's what the politics is.

I’m tracking the polarity of the whole movement, I didn’t understand how politics was attached. I desperately don’t want the whole thing to become a left vs right disaster. We have enough of those.

Re: Bun support is now limited and deprecated

#364
post #73

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…

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.

Re: Bun support is now limited and deprecated

#365
post #73

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…

> 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.

Re: Bun support is now limited and deprecated

#366
post #133

Earlier quoted context omitted.

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.

> 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.

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.

Re: Bun support is now limited and deprecated

#367

Earlier quoted context omitted.

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.

It absolutely is a bad thing. That's why so much effort goes into designing and manufacturing rockets correctly. So the tests go well and you can move onto actual launches. Using that as a metaphor for canary builds displays a lack of knowledge in just multiple areas lol.

[flagged]

Re: Bun support is now limited and deprecated

#368
post #12

I understand their decision. How could the maintainers understand their codebase if most of it was not directly written by them? It is impossible to review the entire rewritten codebase. There are just too many lines of code, 1 million lines to be exact [1]. [1]: https://github.com/oven-sh/bun/pull/30412

This is why I require all my software to have bespoke compilers otherwise how can I trust the devs know what their code is actually running!?

Just because we don't understand or know about compilers or able to read their output does not make them fungible.

In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked.

The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it worked, but nonetheless felt the differences and chose with dollars and usage .

Re: Bun support is now limited and deprecated

#369
post #114

Earlier quoted context omitted.

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.

Bun in its current state absolutely has issues like segfaults. As nice as it is, I moved off of it back to node for production. Folks generally tolerate issues if they believe they’ll get better with time. I know I did for a while. If that confidence collapses, that’s not politics.

But there's no evidence of that in the post. If they had said something like "Bun had bugs X, Y and Z - this Rust thing is the last straw, it's over" -- that would be a reasonable decision, and no one could really complain. But they didn't say that. They just said it "seems like a future headache".
Post reply on HN