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

61–70 of 646 posts

Re: Bun support is now limited and deprecated

#61

Post by sroussey »

maxloh wrote: 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

I don’t think changing from zig to rust suddenly means that don’t know what a certain file contains or how it works or how it relates to other files.

It’s all the same just different syntax. Which, by the way, is why it looks ugly to rust developers. The devs wanted the code to look familiar to them.

I do think they should have called this 2.0 though. Would not feel such a rush (1.3.14 has a few regressions, and no one really cares because there are lots of small rust fires now).

Overall, the bigger issue is that bun chases shiny objects. But never finishes. Just look at test stuff. Most of vistest, but not all. Most of jest, but not all. Most of pnpm, but not all. Now we have image stuff, so most of sharp, but not all. dev server? Most of vite, but you guessed it… not all. Long running process… mostly like node but with memory leaks (and a motivation for rust I’m sure).

When I saw them posting about the Image routines my heart sank. Another shiny object. Coincided with test bugs so I moved to vitest completely.

Re: Bun support is now limited and deprecated

#62

Post by charcircuit »

blain wrote: post #16
satvikpendem wrote: post #9

As long as Deno support is still there I'm not sure why you need anything else. It's not vibe coded slop for one.

Well, apparently Deno is also a slop now: https://github.com/yt-dlp/yt-dlp/issues/16766#issuecomment-4...

Using AI to write code is not necessarily vibecoding nor slop.

Re: Bun support is now limited and deprecated

#66

Post by [deleted] »

colordrops wrote: post #47
hootz wrote: post #2

Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.

Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?

[deleted]

Re: Bun support is now limited and deprecated

#67

Post by garbagepatch »

hootz wrote: post #2

Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.

According to the bun team, it was already vibecoded for months before the Anthropic acquisition.

Re: Bun support is now limited and deprecated

#69

Post by happytoexplain »

colordrops wrote: post #47
hootz wrote: post #2

Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.

Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?

You want the yt-dlp authors to review the entire post-migration Bun codebase?

And what are you referring to as "behavior"?

Re: Bun support is now limited and deprecated

#70

Post by majormajor »

colordrops wrote: post #47
hootz wrote: post #2

Oh well, I really like using Bun and I get kinda sad about the turn they are taking after the Anthropic acquisition. I really want a good Node with batteries included, but I don't want it vibe coded.

Unless specific issues have been identified that were introduced by it being "vibe coded", isn't a reaction to reject it outright without actually checking the ground truth just exhibiting the behavior you are criticizing?

I'm not sure what "exhibiting the behavior you are criticizing" would even mean here.

BUT.

"Ignore anything but actual problems" is a terrible stance to take generally for software and dependency selection. Incidents are fairly sparse, process is much easier to observe. So if you can find connections between process and incident possibility, that's a very reasonable heuristic. And it's easy to find examples of overaggressive LLM usage introducing problems into software.

Post reply on HN