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.
To be clear, I'm not implying support for the merge. I am against this whole YOLO approach to engineering. Just curious how the switch is going since I haven't seen any news since the merge announcement.
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 being executed as Bun.
If the rewrite has been done piece-by-piece or over a longer time period then this history could have been built up over time. As such we will have to wait a while for Bun to exist again.
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!
Name being the same or not, it's what it is in reality (for better or worse)
If by machine translation you mean something like transpiling, that's a technology that has been proven over decades, and the translators were written by hand with some attempt at formal correctness and guarantees. Translating with LLM is much newer and subject to the errors LLMs can create, such as hallucination. And I think a lot of people would still be nervous about translating an entire project of that many lines, even with the best pre-AI translators.
(Hilarious in the way that's terribly sad, of course.)
Not even the same tests, as far as I can tell. That million-line PR touches a lot of test cases...
So just maintain Bun fork of yt-dop, problem solved.
Nobody knows.
Any software engineer that still rejects the concept of agentic coding is frankly NGMI. If you still see AI this way, you simply never bothered to update your priors, which is just not survivable in this career. I do hope you're already independently wealthy.
> I do hope you're already independently wealthy.
Nah, I'm good. I'll be selling llama.cpp slop to people like you when I retire.
And what are you referring to as "behavior"?
BUT.
"Ignore anything but actual problems" is a terrible stance to take generally for software and dependency selection. Incidents are fairly sparse, process is much easier to observe. So if you can find connections between process and incident possibility, that's a very reasonable heuristic. And it's easy to find examples of overaggressive LLM usage introducing problems into software.
The vast majority of new software is written using AI. The problem is not that it is written by AI, but rather than some people treat it like a black box. It is entirely possible to use AI to write code and verify that it is correct. Even Linus Torvalds is allowing AI generated code into the Linux kernel as long as it's managed properly.
How on earth does this follow? It's common, so it should be accepted without scrutiny?
>The problem is not that it is written by AI, but rather than some people treat it like a black box.
Yes, and guns don't kill people. Obviously the issue has two facets. It would be irrational to say "AI is flawless" or "humans are flawless".
Allowing genAI code does not imply blindly trusting genAI code.
>as long as it's managed properly.
Correct. Hence the issue. This was vibe-coding by even the strictest definitions of the term. Vibe-coding is, by definition, not "properly managed".
As far as testing - yes, they do have a test suite that it was checked against during the rewrite, but that still means that any behaviour that wasn't strictly tested for by that suite could have changed and it would still pass.
Not even 10 percent is. Good lord. Go outside and touch grass.