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.
Bun support is now limited and deprecated
111–120 of 646 posts
Re: Bun support is now limited and deprecated
#112Earlier quoted context omitted.
What are you afraid of?
I'm afraid "we" tackle (agressively) the wrong problem, also making it's tough for the maintainers, who did nothing wrong (I have a lot of sympathy towards Bun's developers, they got a lot of ugly feedback within the last month). I don't think AI-written code is the problem at all. Human signs off the changeset the same way as it happened before. I don't care if Rust rewrite did happen using pipeline/harness and LLMs…
[dead]
Re: Bun support is now limited and deprecated
#113This 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…
FYI in case you aren't aware, the rewrite was shipped, and then had to be reverted due to issues being discovered. That's "Jarred's high quality bar" you're so confident in.
[deleted]
Re: Bun support is now limited and deprecated
#114This 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…
A key element of engineering is projecting a current trajectory. Given that, it absolutely makes sense to avoid tools that give you a bad feeling. The easiest time to move away from a tool that will become a train wreck is before you've integrated it.
But what exactly are you projecting? Typically when people have said they have a bad feeling about something (imagine Next.js) it's because they are running into more bugs or they are seeing more production incidents. In this case there has been no chance to observe these things.
Re: Bun support is now limited and deprecated
#115Earlier quoted context omitted.
absolutely, and `its development seems to have taken a turn towards being fully vibe-coded` ungrounded claim confirms the hysteria, I'm afraid
The whole code base is a vibe coded rewrite, half a year after Bun was acquired by Anthropic. I see lots of ground for that claim.
There is no evidence that it was "vibe" coded. It was ported to Rust by an expert engineer using an AI tool using solid SWE practices.
Re: Bun support is now limited and deprecated
#116The "to vibe code or not to vibe code" holy war is now in full swing.
war implies "not vibe code" could win. that's impossible
There's literally nothing that LLMs can build that humans cannot. The only factor influencing people to use AI is time. They trade off a small amount of quality for a large amount of time savings. The tortoise and the hare parable comes to mind.
Re: Bun support is now limited and deprecated
#117We 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.
Writing code is rarely the limiting factor in our work.
Re: Bun support is now limited and deprecated
#118Earlier quoted context omitted.
So it was possible to write ~2 million lines of (mostly) zig, but it's not possible to review ~1 million lines of rust, even though the same test suite included in those 2 million lines of zig can still be used? I'm not convinced the rewrite is a good idea and will work out, but I'm equally unconvinced by your argument.
Its possible to do that over a period of a few years. Sadly, the Rust rewrite happened in (checks notes) 8 days.
[flagged]
Re: Bun support is now limited and deprecated
#119Google 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…
tl;dr: give up, stop trying. just approve the juniors' PR without comment so you have more time to proompt.
Re: Bun support is now limited and deprecated
#120This 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…
“... 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.