Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bun support is now limited and deprecated

github.com

Post reply on HN
Print view View original

301–310 of 646 posts

Re: Bun support is now limited and deprecated

#301

Post by johnfn »

happytoexplain wrote: post #278
johnfn wrote: post #273

Earlier quoted context omitted.

What code is fully, or even primarily, tested by a human? Haven't you heard of automated testing suites, regression testing, conformance testing..?

Test code written by a human counts as "tested by a human". Also, most code is literally tested (manually) by humans in addition to automated tests. You are being pointlessly pedantic.

Bun has a test suite of tens of thousands of tests. For purely non-functional changes, like refactors or rewrites (e.g. a Rust rewrite) I rely primarily on test suites, not manual testing, in order to ensure that nothing regressed. I mean, sure, I am going to poke around, too, but the test suite is the encoding of thousands of obscure bugs and issues over years. There is no way my manual testing will be able to cover the same ground.

Re: Bun support is now limited and deprecated

#302

Post by eddythompson80 »

gryn wrote: post #268
eddythompson80 wrote: post #144

Earlier quoted context omitted.

Pretty normal in many corporate cultures especially ones with high turnover. You get assigned to a team that's "maintaining" a 10 year old code base with few million LoC. The most senior person on the team has been there for a year or 2 and it's just business as usual. You don't know what those 1M+ lines are doing. No one does. It's not a passion of anyone to work on it. You just get a bunch of requirements handed to…

> It doesn't really matter. It does matter, that's why those people quit because it's such a shitshow, progress happens at a glacial pace, more and more defects and slowdowns keep being created even if they have a big QA department/teams and the users are probably trapped because the software is the only thing in town, the bosses are the ones that makes the purchase decisions, or the it comes attached to big and/or e…

yes, of course. I meant "it doesn't really matter" in the sense that businesses have been dealing with this since the beginning of software. Strong ownership and passion was one of the selling points of OSS, but that style of ownership was always very very rare in corporate. It just doesn't really fit with how businesses operate. The "passion" is ARR, not engineering principals. Most software is built, sold, and bought by people who don't use it directly.

Re: Bun support is now limited and deprecated

#303

Post by ozgrakkurt »

johnfn wrote: 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…

> 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

Re: Bun support is now limited and deprecated

#304

Post by phoronixrly »

johnfn wrote: post #301
happytoexplain wrote: post #278

Earlier quoted context omitted.

Test code written by a human counts as "tested by a human". Also, most code is literally tested (manually) by humans in addition to automated tests. You are being pointlessly pedantic.

Bun has a test suite of tens of thousands of tests. For purely non-functional changes, like refactors or rewrites (e.g. a Rust rewrite) I rely primarily on test suites, not manual testing, in order to ensure that nothing regressed. I mean, sure, I am going to poke around, too, but the test suite is the encoding of thousands of obscure bugs and issues over years. There is no way my manual testing will be able to cover…

> Test code written by a human counts as "tested by a human".

Were Bun's tests generated by an LLM? If they were, were they read by a human afterwards to be validated?

Re: Bun support is now limited and deprecated

#305

Post by brailsafe »

johnfn wrote: 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…

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

Re: Bun support is now limited and deprecated

#306

Post by elsonrodriguez »

johnfn wrote: 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…

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

Re: Bun support is now limited and deprecated

#307

Post by BoneShard »

sashank_1509 wrote: post #95

Has bun really shipped using a million line vibecoded PR. I know they merged it, but merging something in a new dir doesn’t mean anything compared to what code is actually running for customers. It’s crazy if the vibecoded rust version is what’s running for customers and not just some experimental hack.

Except it's not vibecoded, it's litteraly the best prompt an LLM can ever get - literal code. If the whole thing ends up as a failure, then it will show that the king is naked.

Re: Bun support is now limited and deprecated

#308

Post by padjo »

jmull wrote: post #263
pizlonator wrote: post #245

I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore” It’s not the same obviously, but here’s why I can’t help but view it analogously: The only truth in software is whether it works or not for whatever your use case is. Even before AI, we couldn’t have known if the author of a piece of software was proceeding with r…

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?

Re: Bun support is now limited and deprecated

#309

Post by umvi »

xmodem wrote: post #42
umvi wrote: post #11

Honestly I hope agentic AI ushers in a new age of minimal-SBOM software. I myself am moving all of my projects towards nearly 100% vanilla where possible. For example, golang. Why use [insert web framework] when you can just use vanilla for 99% of web apps? There's something really satisfying about a go binary with minimal dependencies running in a busybox docker container.

Rather than have complexity centralised and managed, let's generate the same vulnerable code across millions of apps. Great plan.

"A little copying is better than a little dependency." - Go Proverbs [1]

Most complexity is unnecessary. Adding dependencies to your project exponentially increases your project's surface area, which in turn increases its regulatory/cybersecurity burden, especially if your software is a medical device, munition, etc. Why is Echo/Gin/Gorilla/etc better/more secure than vanilla Go's mux? Just anecdotal, but we use the Echo web framework for Go and it's caused nothing but headaches. It does magical XML parsing by default even though we don't deal with XML which gets us flagged in pen tests. Updating from v4 to v5 broke production for us because they made an undocumented server config change that makes all requests have a 30 second timeout. Meanwhile vanilla go has the ability to register routes and middlewares, so what value is Echo bringing to the table? Ditto for lots of other unnecessary dependencies. A lot of times we just need one little thing out of the whole package, and in those cases a little copying (or a little AI generation) is better than a little dependency.

A static go binary with minimal dependencies running in a busybox container has a tiny CVE footprint when run through grype/snyk, etc. Do the same for a NodeJS app with zillions of dependencies running in an ubuntu container and you'll spend all day triaging CVEs.

I'm not saying "roll your own crypto" but I am saying "axios-like packages don't make sense to use any more in a world where AI+vanilla accomplishes the same thing"

[1] https://go-proverbs.github.io/

Re: Bun support is now limited and deprecated

#310

Post by [deleted] »

adamtaylor_13 wrote: post #80

We desperately need some new terminology to describe using LLMs to support development work. "Vibe code" has a strict definition but no one really cares. I have a really hard time believing that the Rust port was 100% "vibed" the way the original definition was laid out. It's a big slushy of emotions that I understand (both positive and negative) but it makes it so hard to actually tells what problem someone actually…

[deleted]
Post reply on HN