561–570 of 646 posts
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.
According to the bun team, it was already vibecoded for months before the Anthropic acquisition.
Earlier quoted context omitted.
I don't think refactoring 1M lines of code into another language within 7 days and merging it to master is responsible. I won't make my code depend on it.
It's not refactoring. It's LLM transpiled.
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…
Anyone who merges such a huge PR of ai generated code doesn’t deserve trust. This is a real black box now, even for the developer himself.
Earlier quoted context omitted.
No, the team mislead people by claiming the rewrite was experimental only to merge 1M lines of unreviewed code merely days later. Responsible software developers don't operate on blind trust, and both the Bun code and the maintainers are highly unpredictable at this point. That's more than sufficient technical grounds to drop an optional and replaceable dependency, especially since there are no user-facing consequenc…
Who did they mislead? A few days later it was no longer experimental and it became the main dev branch as they decided it would be the way forward for development (see the blog post on why). No stable release has been declared yet. Here was the Bun team's message on merge: > It passes Bun's pre-existing test suite on all platforms (and fixes several memory leaks and flaky tests), the binary size shrinks by 3 MB - 8 M…
It's unfortunate that this is what some call "engineering" while labeling actual science and engineering as "politics."
yt-dlp is under no obligation to keep using a dependency from vendors that instantly flip flop and re-frame their own words and actions. That's what actual due diligence and responsible engineering looks like.
Earlier quoted context omitted.
i highly disagree with that framing. the essence of a program is not the fact that people have been running it you could write a great program and never run it. does that mean the program does now not exist? or that it is not a new, unique thing? if anything, the essence of a program is made up by all of the things you mentioned!
The confidence and trust accumulated by the users is paramount. I think that’s what we are talking about here.
Earlier quoted context omitted.
It's not refactoring. It's LLM transpiled.
Sometimes programs work because they rely on undefined behaviour. The users validate that. A famous quote: “we don’t break user space”
Earlier quoted context omitted.
> This is what led to such a high volume of `unsafe` code Which defeats the purpose of having it in rust.
That is incorrect. Identifying where code is unsafe, is a qualitative improvement. Not guaranteed to be complete, but more complete than a language that does not focus on that concern. Moving forward, the benefits of Rust compound. The concern about AI is orthogonal to the concern about moving to Rust. Now there are 2 versions[1] that can be instrumented, regardless of the misgivings about AI. [1] Bun v1.3.14, releas…
> Identifying where code is unsafe, is a qualitative improvement
Agree. There was no need to merge that slop into master though.
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…
The rust rewrite isn’t even out of canary IIUC.
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
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.
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
How much of the windows code has been written by its current maintainers? Little. I feel this argument is not valid, especially for large code bases. Documentation and code quality is what is important, not who wrote the code.