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

421–430 of 646 posts

Re: Bun support is now limited and deprecated

#421

Post by johnfn »

isityettime wrote: post #380
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…

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

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

Re: Bun support is now limited and deprecated

#422

Post by irishcoffee »

__loam wrote: post #410
irishcoffee wrote: post #388

Earlier quoted context omitted.

I don't have the emotional energy to care, actually. This is actually fascinating. How does my opinion matter? Should I join all the socials (this is my only form of social media) and stand on my soapbox and shout into the void? Do I need to express I care so others know I care and have picked a side and have opionions on evrything? I do not care. My opinion does not matter. I can scream into all the voids. I can vir…

Engineers not caring is what leads to people working for scumbags who build socially poisonous technology.

What if I told you I was a stay-at-home dad?

Re: Bun support is now limited and deprecated

#423

Post by rho_soul_kg_m3 »

cesarb wrote: post #338
rho_soul_kg_m3 wrote: post #196

Earlier quoted context omitted.

I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators. They don't have logic, yet programs are logical constructs. So let's call this what it is: randomly-generated code, kinda sorta filtered by humans and tests. It's not because the output distribution has a good match with the expected distribution that it's not random. An LLM that is "hallucinating" is still wor…

> I wouldn't have problems with AI-generated code, but LLMs are not AIs, they are random sentence generators. AI includes a lot of technologies, LLMs being just one of them. Several of these technologies use probabilistic algorithms, so having randomness does not disqualify something from being classified as AI.

And I didn't say it does. Intelligence is not necessarily deterministic, and being random is not the problem with LLMs. The problem is that they are not intelligent: they statistically mimic reasoning and logic, which still could have been acceptable except that they don't generalize well and have double-digit (at best single-digit) error rate percentages.

They also have the worst possible failure mode imaginable: Producing erroneous output that looks perfectly fine and expertly-crafted.

Imagine a food synthesizer machine. You press a button. 80% of the time you get a chicken sandwich, 20% of the time it beeps an error. That's OK. With the LLM version of that, 80% of the time you get a sandwich, 20% of the time you get what looks like a perfect sandwich except that it contains bits of plastic and metal, and you have to start eating it to find the pieces.

"You're absolutely right! Food shouldn't contain bits of plastic. Let me synthesize that again."

Re: Bun support is now limited and deprecated

#425

Post by kentm »

stein1946 wrote: post #365
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…

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

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.

Re: Bun support is now limited and deprecated

#426

Post by root_axis »

getcrunk wrote: post #156

It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers. Or did we forget software inherently is opinionated

Based on the comments I think a lot of people assume the headline pertains to Bun itself.

Re: Bun support is now limited and deprecated

#427

Post by 48terry »

ungovernableCat wrote: post #295

Why are some people so pressed about this decision? From my point of view, if you're truly a vibe code enthusiast wouldn't you be able to just vibe code your own better yt-dlp (or fork the existing one and do whatever you need to do with it)?

Indeed. I've heard a lot of words about how trivially easy vibe coding makes building software, and how just about anyone can build something in no time at all anymore. Even stuff about how people will vibe code one-off private software for everything at all times, and such.

There really shouldn't be a reason for vibe coders to complain about any software decisions. Vibe coding a personal fork you better agree with should be a piece of cake. Isn't that part of the vibe code promise?

Re: Bun support is now limited and deprecated

#428

Post by deadbabe »

getcrunk wrote: post #156

It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers. Or did we forget software inherently is opinionated

This stuff brings bad vibes.

Re: Bun support is now limited and deprecated

#429

Post by BoorishBears »

dbalatero wrote: post #249
getcrunk wrote: post #156

It’s not like they are discriminating on someone’s race or religion. If they don’t want a major vibe coded surface, do they even have to defend that? It’s part their “artistic” license as developers. Or did we forget software inherently is opinionated

Given some posters on the GitHub issue, I get the sense some people feel their religion is being violated.

You don't even have to leave this site: when the original Bun rewrite posts were made, an incredible number of comments were focused, not on Bun, but on Jarred, who I'm assured is a complete rockstar and would never harm Bun.

Unfortunately, his followers don't realize that something like a batteries-included runtime is a huge commitment to build on top of, and governance you can trust matters as much, if not more, than the lines of code.

The way this has been handled is just baffling. A Rust rewrite is supposed to be a freebie for hype, and even an AI rewrite could have been interesting if approached more scientifically and transparently... but instead the opposite of that happened.

Re: Bun support is now limited and deprecated

#430

Post by josephcsible »

sroussey wrote: post #61
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 o…

> It’s all the same just different syntax.

That reminds me of Chris Reigrut's story from https://thedailywtf.com/articles/Holiday_Smorgasbord

Post reply on HN