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

241–250 of 646 posts

Re: Bun support is now limited and deprecated

#241

Post by egorfine »

therepanic wrote: post #111

To be honest, I share primeagen's view that LLMs handle translating code from one language to another quite well. As far as I know, they converted the languages file by file. This is what led to such a high volume of `unsafe` code. Although, in any case let's be honest, this is causing, and will continue to cause, various issues. I find it easier to live with this point of view.

> This is what led to such a high volume of `unsafe` code

Which defeats the purpose of having it in rust.

Re: Bun support is now limited and deprecated

#242

Post by 827a »

cyanydeez wrote: post #213
827a wrote: post #92

Earlier quoted context omitted.

Its possible to do that over a period of a few years. Sadly, the Rust rewrite happened in (checks notes) 8 days.

So this question was never answered: If Zig had so may problems that they felt compelled to rewrite it all in Rust, does that suggest the great Mythos was unable to fix the Zig version? Isn't this suppose to be the most advanced model ever and you're telling me they can't just schedule a cron job that detects and repairs the zig version? Really? Did they just completely admit that the great AI future can't secure a s…

AI is extremely good at rewriting existing code, and rewriting code is a classic engineering productivity trap. That's a tale as old as time; "we need to rewrite the api in Go" said every new midlevel engineering hire ever. Of course, 9 times out of 10 we don't do it, because the unpredictable costs always outweigh the benefit, and in Jarred's case we're starting to see these costs surface. They aren't technical, they're political; broad swaths of the community have lost faith in him and the Bun project.

Re: Bun support is now limited and deprecated

#243

Post by atonse »

josephcsible wrote: post #29
apitman wrote: post #20

Say what you will about Rust vs Zig as languages, the Zig toolchain is definitely the easier of the two to integrate into another project.

This doesn't really have anything to do with the merits of the languages themselves, but rather with the rewrite being entirely vibe coded. If it had been from Rust to Zig instead of from Zig to Rust, I expect the exact same response would have happened.

Mostly unfounded in my opinion. They took the _exact_ same strategy that go did when they moved from C Go to a Go based compiler.

First they essentially wrote a translator that preserved the C idioms (so it wasn't idiomatic go) until they had byte for byte output.

Then they started changing code one by one to be more Go-based.

Bun is doing the same. Right now it is mostly a one for one translation of the zig code. Over time they'll make it more idiomatic Rust.

Re: Bun support is now limited and deprecated

#244

Post by dlopes7 »

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?

No, would you use a proudly vibe-coded banking app?

Re: Bun support is now limited and deprecated

#245

Post by pizlonator »

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 rigor or just trying random stuff until it seemed to work.

In other words, we didn’t judge someone’s software by inspecting their methodology or what tools they used. Heck, we often ended up using software that had no test suite or where the test suite was junk! And so many of us who are fans of memory safety use tools written in C, and vice versa (I’m no Rust fan but I use plenty of tools written in Rust).

So yeah, the logic that goes, “I won’t use your stuff because I don’t approve of your use of AI” is about as believable to me as if you stopped using something because you didn’t like the authors choice of editor

Re: Bun support is now limited and deprecated

#246

Post by guilhas »

burnte wrote: post #231
guilhas wrote: post #172

Earlier quoted context omitted.

So a vibed decision to reject vibed code. Minus minus equals plus?

I think you should read what the bun devs published about their process. It's not just vibed.

Care to share a link? There are 0 posts on Bun blog, or the GitHub page README announcing/explaining the rational for the rewrite, or project direction

Re: Bun support is now limited and deprecated

#247

Post by jmull »

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…

Not sure what seems "political" about this.

When deciding to support a given thing, you have to make a determination as to whether it's worth the effort or not.

You don't simply ignore unknowns. That effectively means assigning the unknowns zero cost, which is unlikely to turn out to be true. Generally, the more unknowns, the higher the risk, and the higher the risk, the higher the estimated cost.

There are a lot of unknowns about vibe bun right now.

One effective strategy for dealing with unknowns is to turn them into knowns if you can. Here, that probably means waiting to see how vibe bun turns out.

If it turns out to be stable and highly compatible, at some point in the future, they can always pick up support then.

Re: Bun support is now limited and deprecated

#248

Post by happytoexplain »

johnfn wrote: post #191
gpm wrote: post #178

Earlier quoted context omitted.

> Saying "because they vibe coded we are dropping support for Bun" sounds political. I don't think "political" is necessarily a bad thing. Engaging in politics is how you shape the world. The mere act of writing and maintaining yt-dlp is quite political considering the context of IP law and enforcement that we live in. It happens that in this case that I'd disagree with their politics if that's why they are dropping…

That's not what I meant by political. I meant political in the more modern sense of "appealing to emotion rather than thought". EDIT: Everyone is rightfully calling me out that this doesn't make a lot of sense. What I meant is that the move is driven by ideology. I think there is a lot of overlap between politics and ideology, and an increasing amount of overlap between ideology and emotion. But it's fair enough to c…

I can't see how this counts as "political" or "ideological" by your definition unless you believe that emotion can't exist as part of any decision, in which case you should give up interacting with human beings entirely.

Regardless, the decision was 99% logical. In fact, even the emotional parts are laudable. For example, I love software. That's an emotion. If you disagree with that foundation, we will fundamentally never be able to converse with each other about what's best for software.

Re: Bun support is now limited and deprecated

#249

Post by dbalatero »

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.

Re: Bun support is now limited and deprecated

#250

Post by jameson »

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…

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

Your argument could go other way too. Why haven't they landed if they're so confident with the change?

Post reply on HN