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

591–600 of 646 posts

Re: Bun support is now limited and deprecated

#591

Post by tln »

tln wrote: post #75

This is about the rust conversion but that has not been released. > Due to foreseeable compatibility and security issues Hmm, Zig bun crashes plenty. I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites. Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would b…

I found this:

    bun upgrade --canary
...will install a very recent build, with version 1.4.0

I still hope there is a beta release.

Re: Bun support is now limited and deprecated

#593

Post by 827a »

justinhj wrote: post #582
cyanydeez wrote: post #213

Earlier quoted context omitted.

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…

I was thinking along similar lines today. An AI assisted audit of the issues that caused segfaults could find and implement safe memory management patterns in Zig. It sounds like the Rust port process essentially has had to do this anyway when it analyzed all of the places unsafe is needed and started mitigating some of them. The project also sounds like it has unique memory management problems in its nature: native…

Zig has a "Zero AI" policy. Bun has had to maintain an internal fork of Zig with various AI-assisted fixes that have resulted in real performance and stability gains for the runtime. Its, arguably, a decent reason to decouple from Zig.

The challenge is: They already were decoupled. They've forked Zig. If your desire is to make a bet on generated code and reasoning as the entire future of software development, as Jarred and Bun have; why would you chain yourself to the crazy political nightmare that is the Rust project, when you've already got a language & runtime that's treated you well, is forked, your contributors know well, etc? Literally: Why can't these issues be fixed within the context of BunZig? Why don't they want to own the whole stack?

Re: Bun support is now limited and deprecated

#594

Post by 12_throw_away »

literalAardvark wrote: post #555
gryn wrote: post #268

Earlier quoted context omitted.

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

People quit because maintenance is an unsexy job with poor career prospects. The code base itself has never and will never matter in the big picture

> The code base itself has never and will never matter in the big picture

Clearing my throat: I am the first person to tell everyone on the team (repeatedly, until they are sick of hearing it) that the users, use cases, and organizational objectives are always more important than the technology.

But, in "the big picture" - the Linux codebase doesn't matter? The codebase that powers AWS doesn't matter? Hell, the Microsoft Office codebase doesn't matter? Look at what's happening to Windows when they treat it like the codebase doesn't matter.

For a tech org, the codebase is the reification of all of your objectives, all of your knowledge about your users and use cases and processes. Long term, a mature codebase plus people who understand it is one of the most valuable things you have. When orgs don't realize this, when they treat their workers and their work product as disposable commodities, we call this "enshittification."

Re: Bun support is now limited and deprecated

#595

Post by J_Shelby_J »

12_throw_away wrote: post #594
literalAardvark wrote: post #555

Earlier quoted context omitted.

People quit because maintenance is an unsexy job with poor career prospects. The code base itself has never and will never matter in the big picture

> The code base itself has never and will never matter in the big picture Clearing my throat: I am the first person to tell everyone on the team (repeatedly, until they are sick of hearing it) that the users, use cases, and organizational objectives are always more important than the technology. But, in "the big picture" - the Linux codebase doesn't matter? The codebase that powers AWS doesn't matter? Hell, the Micro…

It’s more like shareholder suicide.

Re: Bun support is now limited and deprecated

#596

Post by LtWorf »

Rexxar wrote: post #545
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 use Node.js or Bun, so I'm little out of touch. But what need 1 millions lines of code as the js engine itself is a library ?

I've been wondering the same.

Re: Bun support is now limited and deprecated

#597

Post by LtWorf »

crowcroft wrote: post #543
manquer wrote: post #368

Earlier quoted context omitted.

Just because we don't understand or know about compilers or able to read their output does not make them fungible. In old days we chose between Turbo/Borland C, Quick C and GCC. We didn't think them same or trust blindly even if we didn't know how they worked. The best developers hand optimized assembly for sub routines which they knew compilers were not good at, the rest of us sure didn't understand how any of it wo…

Part of what I’m getting at is exactly your point that we used to think about what compiler to use and didn’t always blindly trust them. If you have enough tests at what point does AI rewriting software in a different language become close enough to ‘deterministic’? Maybe never, maybe not.

The AI will normally cheat and edit the tests.

Re: Bun support is now limited and deprecated

#598

Post by LtWorf »

insanitybit wrote: post #575
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

I don't think they have to defend it, but I don't think there's any issue questioning the validity of the approach.

If you don't like a decision don't harass, fork.

Re: Bun support is now limited and deprecated

#599

Post by orf »

zarzavat wrote: post #391
giancarlostoro wrote: post #348

Earlier quoted context omitted.

How many lines of translated code would have been acceptable? What about before AI all the machine translated projects that people used for years without a single complaint? The person who did this was the lead for Bun from the get go no? So it stands to reason that they are one of the highest authorities in Bun itself.

What is the essence of a program? The name? No. The author? No. The test suite? No, testing is hard and most projects don't do enough of it. The code? Not really, code can be rewritten. The history of the program being executed by its users? Ding ding ding. Yes, it's this one. Bun no longer exists. What exists now is a program that has the potential to be Bun but at this time is not Bun because it has no history of b…

The essence of a program is all of those things. The omission of any one of them makes a program almost worthless.

Re: Bun support is now limited and deprecated

#600

Post by retromario »

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.

In the past 18 months I've seen experienced developers turn out incredible work using llm-assisted tools, over and over again. With the right harnesses, processes and result-oriented testing, you can simply produce so much more high-quality work.

I know it's anecdotal, but I have so much data from my own experiences and those of my peers that I know these new tools are here to stay. It also makes me believe that those studies are either flawed or out of date.

Post reply on HN