[dead]
Bun support is now limited and deprecated
351–360 of 646 posts
Re: Bun support is now limited and deprecated
#352Earlier quoted context omitted.
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.
He plays around with a toy project in a separate branch, tells everybody to relax that's just an experiment that has no chance of being merged, then abruptly merges 1m lines of code not seen by a human, effectively zeroing out all the contributions ever made by anyone to bun, including contributions in progress. At the same time, his arguments in favor of Rust are sound, there is no doubt about that.
>that's just an experiment that has no chance of being merged
Yeah he never said that.
Re: Bun support is now limited and deprecated
#353I 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 r…
> 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”
So let's say they up the ante and set up a cron job to rewrite the entire codebase in a new language on the first Monday of every month: from Rust to C++ to Go to Swift and back again.
For customers using the product, that's basically the same as a maintainer switching editors? Irrelevant detail?
Re: Bun support is now limited and deprecated
#354This 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…
Reading and understanding code is more difficult than writing code.
It is significantly easier to modify code that you personally wrote, or code that you have read and understood to fix an issue in previously. This is why the maintainers of a project change slowly over time and it takes a long time for new ones to get up to speed.
All of Bun has been rewritten by a tool. In a different language that maintainers may not be fully proficient in.
Even though the rewrite was done well, and even if we assume it's functionally equivalent to the old Zig code, there will still be future issues. And ALl of the maintainers are essentially now new hires who have never seen that code in their lives.
It's not "politics" to have an ounce of sense to foresee problems in such a project as a dependency.
Re: Bun support is now limited and deprecated
#355Earlier quoted context omitted.
>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” That's wild. You should read it as being nowhere in the same ballpark nor adjacent ballparks as that.
Yea for real. Like how is it possible to even formulate that as anywhere near the subject matter in any way, shape or form :S
People addicted to chatbots appear to be suffering from cognitive atrophy.
Re: Bun support is now limited and deprecated
#356Earlier quoted context omitted.
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
https://news.ycombinator.com/item?id=48073680
There's been lots of talk about it here and on his twitter and such.
Re: Bun support is now limited and deprecated
#357Earlier quoted context omitted.
studies suggest nothing. i've released a massive number of features in the last year for several projects that i estimate would have taken me multiple years to put together in a much more mentally exhausting way.
Your drive-by comments are unwelcome. You can estimate all you want, but the data is collating, and it isn't within your worldview.
It is healthy to question results: That's good science.
This result wouldn't surprise me if the tooling was limited to, say, copilot :)
It would surprise me if it included tooling like Claude Code. Which seems unlikely, given its recency.
Re: Bun support is now limited and deprecated
#358To 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.
primeagen's view He's a content creator on youtube, a celebrity, not a serious programmer.
He was a software engineer at Netflix before turning to content creation. It is also clear watching his videos that he knows his thing. As an experienced programmer myself, I find his commentary to be way too relatable to be just bluff.
He may not be Don Knuth, Linus Torvalds, John Carmack or Fabrice Bellard. But he is definitely a serious programmer. That he livestreams doesn't make him less of a programmer.
Re: Bun support is now limited and deprecated
#359I 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 could the maintainers understand their codebase if most of it was not directly written by them?
Counterpoint: I look back at code I wrote a few years ago and just take it on faith that I knew what I was doing at some point. That's still better than never knowing, but it requires faith--faith in a human, vs. faith in an LLM.
Re: Bun support is now limited and deprecated
#360Earlier quoted context omitted.
Most people probably think the text editor used would have no meaningful effect on the code written. I don't think many would say the same for LLMs. Maybe vibe bun is just as good or better than old bun, but how would we know at this point? > ...we couldn’t have known if the author of a piece of software was proceeding with rigor...we didn’t judge someone’s software by inspecting their methodology... That's not true.…
> Maybe vibe bun is just as good or better than old bun, but how would we know at this point? By considering objective facts like efficiency, performance, error rates, security vulns etc. like we always do?
These objective facts aren't known right now for vibe bun.
Someone would have to do a bunch of work to establish these things.