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

181–190 of 646 posts

Re: Bun support is now limited and deprecated

#181

Post by omnimus »

johnfn wrote: post #139
apalmer wrote: post #131

Earlier quoted context omitted.

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 produc…

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.

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.

Re: Bun support is now limited and deprecated

#182

Post by cdelsolar »

b40d-48b2-979e wrote: post #117
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…

I'm using LLMs to assist my development and I'm measurably (in all the ways we engineers could possibly care about) doing better work faster. Studies suggest you aren't any faster and may in fact be slower. It's difficult to study such a new tech, but even optimistically, empirical evidence is only showing a ~3% gain in some domains. Writing code is rarely the limiting factor in our work.

studies suggest nothing. i've released a massive number of features in the last year for several projects that i estimate would have taken me multiple years to put together in a much more mentally exhausting way.

Re: Bun support is now limited and deprecated

#183

Post by guilhas »

johnfn wrote: post #152
hnav wrote: post #90

Earlier quoted context omitted.

a vibecoded rewrite right after being acquired is not political?

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?

Cool experiment? true

Cool production? false

Re: Bun support is now limited and deprecated

#185

Post by registeredcorn »

merb wrote: post #104

Google did something similar with golang. Of course it was a tool based rewrite and they did lots of tests but some bugs still emerged. People should stop being mad about a company that delivers a tool that is about shipping software faster. The world does not resolve around high quality software, the world resolves around things that might need a reboot every other day, that was never touched for over 2 years. Thing…

Do not vote on this comment! I am a server! :)

Re: Bun support is now limited and deprecated

#186

Post by throwaw12 »

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

Re: Bun support is now limited and deprecated

#187

Post by tomjakubowski »

hexage1814 wrote: post #103
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

[flagged]

> in many aspects of human history, we have traded understanding for convenience—that's the reason why we buy food at the supermarket instead of hunting for our meal.

You could always take a job on a cattle ranch or an abattoir or meat-packing plant, or watch a How It's Made documentary, and get some understanding of how the sausage gets made and put on the supermarket shelf for your convenience. This was also true as we built abstractions in computer technology: you could start off learning a high level language, then learn a lower level one, then study or build an operating system kernel, a compiler, an assembler, machine code, and then crack some books on microprocessor architecture and signal processing. You could always "go deeper" if you wanted to. And there is a payoff: understanding at a deeper level helps you get things done better at the higher levels (e.g.: understanding the concept of memory hierarchy helps you lay out data structures to make code faster).

There is no such step for slop-coded codebases: you become entirely dependent on a context-limited LLM to have a shot at even approximating some understanding. The proponents of this style will tell you, don't look at the code. It's the antithesis of every other abstraction we've built in computing.

Perhaps more productively, you treat the slop as a black box and build something understandable around it.

This is also why the notion that developers in the future will be committing LLM prompts in English to repositories instead of code written in a programming language is so foolish. I am saying this as someone who uses LLMs quite a lot to help with generating and understanding code.

Re: Bun support is now limited and deprecated

#188

Post by dogleash »

johnfn wrote: post #120
king_geedorah wrote: post #110

Earlier quoted context omitted.

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

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.

So, you're fanboying?

If we're gonna fight, lets go xbox vs playstation. Javscript runtimes are a snoozefest.

Post reply on HN