Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
There were very many open pull requests from the community that were all invalidated overnight for something that same community was assured was merely an experiment.
The normal process would be "hey, this experiment is going well, we've made this plan, come help us shake out the new codebase for the switchover in X time." None of that happened. There wasn't even an announcement, just a silent commit that trashed hard work from hundreds of community members.
None of that is needed. Nobody benefits from all that time wasting bureaucracy/corpo speak. Bun is quick to deliver new features and bug fixes. With this change, the hope is that'll only get faster.
All those PRs can be fed thru Claude and converted to rust and then manual polish can be added.
Bun is riddled with bugs. That's what moving fast and breaking things gets you. It gets you famously bad codebases that are nightmares to work with and slow you down over time as your sins catch up with you. Vibecoding is not enough.
Then why do you care? If target users (developers) face issues with bun, they will stop using it. Go back to Node or switch to Deno.
Bun has bugs? yes. Do they affect vast majority of users? Not really. Been using bun for about 3 years; never had an issue with it.
Are you interested in the discussion that was taking place before you popped in or are you just here to get outraged that something you clearly identify strongly with is getting criticism for making poor choices?
"Because the discussion was interesting" is why I care.
Discussion was not interesting. It was built on speculation as facts and lies as facts.
The worst is "hey they are running proprietary fork and not open source anymore" when the code is available in plain sight. Canary build is available with one command. The stupid article made a huge stink about it without this key fact. Now they added the update but damage is done.
No, that's not correct. That is the discussion started by the article, and the one continued in many other comment threads, even including this one far further upthread. Conversations drift over time, and this thread has evolved into a subdiscussion on the topic of the rewrite itself. If this is not what you would like to discuss, I suggest you visit the other threads.
If you would like to join us in this thread now that this misunderstanding has been corrected, please, share your thoughts on the Bun community, what the "Bun community" even is, and how it has been impacted by a sudden, unannounced rewrite.
Bun "contributor community", that provides significant amount of code contribution, is largely non-existent. Almost all of the work is done by Jarred and others at Oven. If someone still wants to contribute, they can do so on Rust. There is no reason to give warnings and plenty of time just to delay something like this when doing it rapidly is possible (now with AI).
Bun "user community", is not affected by this at all (yet) except the ai doomers/zig fanatics.
When v1.4.0 is fully released, and if Bun team can't get it to full feature (and no new serious bugs) parity with last zig version within a few versions (let's say v1.4.2), then there will be real effects.
I will be testing v140 after release. As a bun user community member, I expect no new type of crash, slightly faster perf/less memory usage and move on with my life.
A rewrite like this is unprecedented but doesn't mean impossible. I am cautiously optimistic.
This statement of a lack of community is at odds with the plentiful pull requests that were open before the rewrite.
This is, as you say, unprecedented. Not impossible, cautious optimism is a fine response. But to bring back a point I made earlier in the new old light: Then let's be cautious. Let's do some announcements ahead of time. Let's get some people in and get some physical hands on the codebase. Let's not go from "Stop freaking out, it's just an experiment!" to a silent merge to main in a week. That causes reduced trust in the project from those even just a hair less optimistic than you, and that's clearly unhealthy for the project no matter how you define "the community."
If an experiment goes wildly successful beyond imagination, rapid pivot is only natural.
Jarred earned the trust by providing value. People who say trust is reduced without actually seeing the result, never had trust to begin with.
It's not like they merged and dumped it on to the world immediately. It's available as canary. They are doing their own dog fooding. Prisma is using the canary successfully.
As long as oven team can deliver a zig version equivalent stable bun, it is a success in my book. After that they can focus on resolving as many unsafe as possible and then the real benefits will materialize.
Developer community. "Open source" historically implied that an interested developer might hack on the code and submit their changes. But if the entire code-base is rewritten by the maintainer every year, then there's no developer community.