9 ms·

Why does changing to Rust kill the project? I don't understand the point here.

by junon 3mo ago

pjmlp 3mo ago
Definitely, it was a possible reason why Zig actually matters in the industry. Now it is a Deno clone, both without anything enticing over node.js.
Cthulhu_ 3mo ago
Yeah same, according to one of the Zig team members, the original source code wasn't all that anyway. But this is HN, a subsection of which places a high importance on what language something is written in, moreso than what it does (feels like).
- gipp 3mo ago
  I don't think the GP had anything to do with the language change itself. More that it marks a clear point of Anthropic taking ownership and governance of the project in a less open direction.
- flohofwoe 3mo ago
  An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zig). It also might explain why porting from Zig to Rust was done 'on a whim', the actual source code (and the idea of 'original work') never seemed to be all that important to the author (and I wouldn't be surprised if the project does more language-hopping in the future heh).
  - realo 3mo ago
    I read your link, written by Bun's author and totally get his thinking. In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun. In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
    - ambicapter 3mo ago
      Are you really "doing things securely" when you use as many unsafe blocks as the Rust port of Bun does?
    - LtWorf 3mo ago
      I don't think you can claim your code is secure, or can claim anything at all about your code, if you haven't written the code and have no idea what's in there. Rust protects against a rather small group of memory error, if and only if the unsafe sections are actually correct. And nobody knows if they are correct or not, plus there can be millions of logical errors that can be exploited. See how many CVEs uutils has… quite a lot for a supposedly secure rewrite of GNU coreutils.
deleted 3mo ago
[deleted]
_pdp_ 3mo ago
I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.
- petcat 3mo ago
  I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
  - pmarreck 3mo ago
    Anyone actually using it knows it is better. The C interop is so good that there is no use-case where C is the better option IMHO
    - 59nadir 3mo ago
      You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.
      - lstodd 3mo ago
        By my own admission I wrote ~100K loc in zig-head. Having a background in linux kernel development of all things I can tell you that Zig is so much better than C or Rust, that I think linux kernel rush to rust is misguided.
        59nadir 3mo ago
        I haven't even stated whether I agree with the opinion that Zig is worth it, in fact I do think Zig is worth it for a large set of problems and I wrote Zig for years, I am stating simply that I would never trust anyone who's self-admitting that they don't even write the language they're arguing for when it comes to opinions on whether it's good or not. It's not really about whether Zig is good, it's about someone who doesn't even write the language and doesn't even know it, not having a valuable opinion on it.
embedding-shape 3mo ago
I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.
- atonse 3mo ago
  The whole point of the outrage was that 1.4 was merged into main. Publicly. So I’m not sure what you mean. Everything is in the open: PR #30412
  - jdiff 3mo ago
    That PR is the rust rewrite. That's some time in the past now. As of this comment, there is no tagged 1.4 release. This is the present. Anthropic is using apparently a version of Bun that is not publicly available. This is orthogonal to it being Rust-based, as all Bun releases now will be.
    - simonw 3mo ago
      It's publicly available in the GitHub repository and if you run "bun upgrade --canary" - https://github.com/oven-sh/bun/releases/tag/canary https://github.com/oven-sh/bun/releases/tag/canary
      - jdiff 3mo ago
        That commit (and main) still purports to be 1.3.14, the version numbers haven't changed. Does that not still suggest Anthropic is using something else?
        simonw 3mo ago
        I think Bun/Anthropic should document which commit hash their "1.4" as shipped in Claude Code uses.
    - alexjurkiewicz 3mo ago
afavour 3mo ago
The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. We don’t know what’s actually in it.
- firesteelrain 3mo ago
  Moving the goalposts?
  - afavour 3mo ago
    No? I think OP’s comment was very clear: > The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version. > And so, the FOSS project "Bun" silently dies There’s no implication that it’s because of the switch to Rust.
    - firesteelrain 3mo ago
      > The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. I was responding to your GP comment. For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
      - afavour 3mo ago
        That seems illogical to me. We’re only allowed to have one objection to a project and once that’s used up we can’t air another? FWIW I don’t think people have forgotten the original objection either!
        firesteelrain 3mo ago
        You can; it feels contrived and very social justice warrior/anti Anthropic (which on HN is in of itself almost a meme now). The main reason was because of the blanket AI move which I could understand.
foxes 3mo ago
As an open source - community driven project? Have you looked at the repo on github? Theres thousands of PRs from claude agents or whatever. Yeah really feels like a worthwhile place to contribute lol.
- embedding-shape 3mo ago
  > As an open source - community driven project? Have you looked at the repo on github? FOSS as in FOSS - Free and Open Source Software. Has nothing to do with if it's community driven or not, I'm strictly talking about FOSS.
atonse 3mo ago
It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake. I’ve never met Jared or the bun team but I don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in? It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.
- well_ackshually 3mo ago
  [flagged]
  - CrimsonRain 3mo ago
    What a load of bs. > Inevitable collapse According to who? You? The well ackshually guy? > Low in trust before acquisition Cite your sources. > Unreleased version v140 is the canary version which has been available for a long time. https://github.com/oven-sh/bun/releases/tag/canary https://github.com/oven-sh/bun/releases/tag/canary > Not open source anymore Who died and made you the dictator of open source? Your post is just a bunch of opinions and lies and speculation wrapped as facts.
    - embedding-shape 3mo ago
      > v140 is the canary version which has been available for a long time. https://github.com/oven-sh/bun/releases/tag/canary https://github.com/oven-sh/bun/releases/tag/canary What is actually going on with that tag? It has files uploaded in Jul 29, 2024 and files uploaded "6 hours ago" (some hours after Simon first published his blog post). Do they not do proper releases with immutable tags and instead use one tag kind of like a git branch that mutates and changes over time?
      - 3mo ago
locknitpicker 3mo ago
> Why does changing to Rust kill the project? I don't understand the point here. I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors. Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it. I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.
- conartist6 3mo ago
  of course they also gave away their own claim to be the copyright owner, but that's neither here nor there ; )
- brabel 3mo ago
  > I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision… Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime! The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
- CrimsonRain 3mo ago
  A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. That somehow kills the project. ok!
  - locknitpicker 3mo ago
    > A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. No,not really. There is only one point: does Bun acknowledge that past contributors still hold copyright over the Rust rewrite?
OJFord 3mo ago
Emphasis on the FOSS project. The v1.4 mentioned is not (yet?) open source, Claude Code is essentially using a proprietary fork, was GP's point.
- goo0000fy 3mo ago
  [flagged]
  - OJFord 3mo ago
    From the article: > For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version. Which is still true as I write this comment.
    - kelnos 3mo ago
      A charitable interpretation is that the version of bun inside Claude Code corresponds to some recent state of their public git repository, so if you clone that, you more or less get the same thing. I don't see what it would buy Anthropic to have some sort of secret internal fork with special private code in it.
      - goo0000fy 3mo ago
        bun upgrade --canary
    - simonw 3mo ago
      The code is on GitHub in the "main" branch, it's only unreleased in that it hasn't been tagged with a version number yet.
      - goo0000fy 3mo ago
        yeah the word "unreleased" makes it sound so mysterious i am a clankersceptic as much as the next guy and i hate "anthropic" for participating in the murder of innocent people (maven "smart" system, offers them as a provider to the pedo criminal unitedstatistan government) but this whole "unreleased" framing is just manufacturing drama / lack of knowledge
jeroenhd 3mo ago
My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim. I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me. Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.
- muglug 3mo ago
  The language an application is authored in does not matter to me, as a user. I care that it is widely-used (safety in numbers), that it works, and that it is fast. It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
- atonse 3mo ago
  Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
  - jdiff 3mo ago
    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.
    - CrimsonRain 3mo ago
      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.
stymaar 3mo ago
Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared. “bun the JavaScript runtime ” is not dead though.
- Matl 3mo ago
  I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
  - Dylan16807 3mo ago
    Surely a lot of review has happened in the last two months?
    - endospore 3mo ago
      Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated. Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
      - Tadpole9181 3mo ago
        This feels like such an absurd, bad faith take I keep hearing. In Zig, every single memory operation is unsafe. And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors. There's too much, sure, but can we at least be honest and reasonable?
        endospore 3mo ago
        My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it) > must interface with C code that has no safe interface Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2x as many unsafes. And mind you if you haven't read the code, the vast majority of unsafe blocks in bun are for raw pointer access to local (Rust) objects because their ownership was a mess both before and after the rewrite. Also funnily enough a lot of the access patterns are wrong (in the Rust sense), leading to hundreds of new undefined behaviors. > be honest and reasonable Well, well. Talking about dishonest and unreasonable behavior, why is bun releasing a new version before solving any of those glaring issues? I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.
hoppp 3mo ago
Bun is now mainly the runtime for claude code. All changes will go in to make claude code better. It's not about making the dev experience better than node, that use-case is now secondary.
amazingman 3mo ago
I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic.

Why does changing to Rust kill the project? I don't understand the point here.

by junon 3mo ago

Why does changing to Rust kill the project? I don't understand the point here.

pjmlp 3mo ago

Definitely, it was a possible reason why Zig actually matters in the industry. Now it is a Deno clone, both without anything enticing over node.js.

Cthulhu_ 3mo ago

Yeah same, according to one of the Zig team members, the original source code wasn't all that anyway. But this is HN, a subsection of which places a high importance on what language something is written in, moreso than what it does (feels like).

gipp 3mo ago
I don't think the GP had anything to do with the language change itself. More that it marks a clear point of Anthropic taking ownership and governance of the project in a less open direction.
flohofwoe 3mo ago
An interesting tidbit is that large parts of the original Bun source code was a line-by-line port of esbuild from Go to Zig (mentioned here: https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust), tbh this lowered my respect for the project a bit (a line-by-line port simply isn't as interesting as original work), and it might also explain the subpar Zig code quality (a line-by-line port from Go to Zig simply won't result in idiomatic Zig). It also might explain why porting from Zig to Rust was done 'on a whim', the actual source code (and the idea of 'original work') never seemed to be all that important to the author (and I wouldn't be surprised if the project does more language-hopping in the future heh).
- realo 3mo ago
  I read your link, written by Bun's author and totally get his thinking. In the current world of cyber weaknesses everywhere, infrastructure must be solid and rust is a better choice than zig for something like bun. In other words, bun is not a demo of zig programming that happens to do useful things. Bun does useful things, and must do them securely. That is its number one priority, language is secondary, inasmuch as it helps doing useful things securely.
  - ambicapter 3mo ago
    Are you really "doing things securely" when you use as many unsafe blocks as the Rust port of Bun does?
  - LtWorf 3mo ago
    I don't think you can claim your code is secure, or can claim anything at all about your code, if you haven't written the code and have no idea what's in there. Rust protects against a rather small group of memory error, if and only if the unsafe sections are actually correct. And nobody knows if they are correct or not, plus there can be millions of logical errors that can be exploited. See how many CVEs uutils has… quite a lot for a supposedly secure rewrite of GNU coreutils.

deleted 3mo ago

[deleted]

_pdp_ 3mo ago

I am impartial on the matter, but I think one of the reasons Bun became a thing in the first place was because of Zig attracted a small but very active developer community. Switching from Zig to Rust effectively alienates that community.

petcat 3mo ago
I think the Zig people are really just worried that maybe Zig itself is a DOA language before it has even reached 1.0 because it doesn't offer enough over C for any serious use and their flagship project has now abandoned it.
- pmarreck 3mo ago
  Anyone actually using it knows it is better. The C interop is so good that there is no use-case where C is the better option IMHO
  - 59nadir 3mo ago
    You, by your own admission, haven't even written a single line of Zig despite having ~31 Zig projects on GitHub. I don't think your knowledge of the language is to be trusted in almost any capacity. This might seem harsh but I don't trust someone who's experience with a language amounts to slopping out 30+ repositories and not even engaging with the language normally.
    - lstodd 3mo ago
      By my own admission I wrote ~100K loc in zig-head. Having a background in linux kernel development of all things I can tell you that Zig is so much better than C or Rust, that I think linux kernel rush to rust is misguided.
      - 59nadir 3mo ago
        I haven't even stated whether I agree with the opinion that Zig is worth it, in fact I do think Zig is worth it for a large set of problems and I wrote Zig for years, I am stating simply that I would never trust anyone who's self-admitting that they don't even write the language they're arguing for when it comes to opinions on whether it's good or not. It's not really about whether Zig is good, it's about someone who doesn't even write the language and doesn't even know it, not having a valuable opinion on it.

embedding-shape 3mo ago

I don't care about the language, but pre-releases the community don't get access to but released (Anthropic) applications do have access to, feels a bit too on the nose after the acquisition.

atonse 3mo ago
The whole point of the outrage was that 1.4 was merged into main. Publicly. So I’m not sure what you mean. Everything is in the open: PR #30412
- jdiff 3mo ago
  That PR is the rust rewrite. That's some time in the past now. As of this comment, there is no tagged 1.4 release. This is the present. Anthropic is using apparently a version of Bun that is not publicly available. This is orthogonal to it being Rust-based, as all Bun releases now will be.
  - simonw 3mo ago
    It's publicly available in the GitHub repository and if you run "bun upgrade --canary" - https://github.com/oven-sh/bun/releases/tag/canary https://github.com/oven-sh/bun/releases/tag/canary
    - jdiff 3mo ago
      That commit (and main) still purports to be 1.3.14, the version numbers haven't changed. Does that not still suggest Anthropic is using something else?
      - simonw 3mo ago
        I think Bun/Anthropic should document which commit hash their "1.4" as shipped in Claude Code uses.
  - alexjurkiewicz 3mo ago

afavour 3mo ago

The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. We don’t know what’s actually in it.

firesteelrain 3mo ago
Moving the goalposts?
- afavour 3mo ago
  No? I think OP’s comment was very clear: > The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version. > And so, the FOSS project "Bun" silently dies There’s no implication that it’s because of the switch to Rust.
  - firesteelrain 3mo ago
    > The objection isn’t to the language. It’s to Claude using a version of Bun that is not available to us. I was responding to your GP comment. For weeks, it was uproar over the blanket AI move to Rust and now it’s this reason. That’s why I said the goalposts are being moved.
    - afavour 3mo ago
      That seems illogical to me. We’re only allowed to have one objection to a project and once that’s used up we can’t air another? FWIW I don’t think people have forgotten the original objection either!
      - firesteelrain 3mo ago
        You can; it feels contrived and very social justice warrior/anti Anthropic (which on HN is in of itself almost a meme now). The main reason was because of the blanket AI move which I could understand.

foxes 3mo ago

As an open source - community driven project? Have you looked at the repo on github? Theres thousands of PRs from claude agents or whatever. Yeah really feels like a worthwhile place to contribute lol.

embedding-shape 3mo ago
> As an open source - community driven project? Have you looked at the repo on github? FOSS as in FOSS - Free and Open Source Software. Has nothing to do with if it's community driven or not, I'm strictly talking about FOSS.

atonse 3mo ago

It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. I feel weird having to defend reality; reality being that it was merged nearly 2 months ago and tons of people have had their pitchforks out without a shred of actual evidence that this made bun worse in any measurable way. But they still insist it was a mistake. I’ve never met Jared or the bun team but I don’t understand all the personal attacks, I just feel the need to correct the facts. Literally who cares what language a JS toolset is written in? It’s not like they ported JavaScriptCore (the actual JS runtime) to rust even. All that stuff is largely untouched.

well_ackshually 3mo ago
[flagged]
- CrimsonRain 3mo ago
  What a load of bs. > Inevitable collapse According to who? You? The well ackshually guy? > Low in trust before acquisition Cite your sources. > Unreleased version v140 is the canary version which has been available for a long time. https://github.com/oven-sh/bun/releases/tag/canary https://github.com/oven-sh/bun/releases/tag/canary > Not open source anymore Who died and made you the dictator of open source? Your post is just a bunch of opinions and lies and speculation wrapped as facts.
  - embedding-shape 3mo ago
    > v140 is the canary version which has been available for a long time. https://github.com/oven-sh/bun/releases/tag/canary https://github.com/oven-sh/bun/releases/tag/canary What is actually going on with that tag? It has files uploaded in Jul 29, 2024 and files uploaded "6 hours ago" (some hours after Simon first published his blog post). Do they not do proper releases with immutable tags and instead use one tag kind of like a git branch that mutates and changes over time?
    - 3mo ago

locknitpicker 3mo ago

> Why does changing to Rust kill the project? I don't understand the point here. I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision and instead is a ploy to shed copyright claims from past contributors. Now, based on comments from this thread, the formerly FLOSS project is somehow granting special access to a corporation that apparently is invested in going way out of their way to push implementations that consume the complete rewrite before the world has access to it. I for one won't be touching Bun. This doesn't pass the smell test. It feels like a bait-and-switch in progress.

conartist6 3mo ago
of course they also gave away their own claim to be the copyright owner, but that's neither here nor there ; )
brabel 3mo ago
> I'm concerned that the complete rewrite in an entirely different language is not a sound technical decision… Even if this was a terrible technical decision, it is a good, maybe even unavoidable, business decision. And I don’t think moving to Rust was a bad technical decision at all, given Zig is unstable and constantly changing, and that it’s not memory safe, which is a big problem for something like a JS runtime! The reason it’s a necessary business decision is that Bun is owned by an AI company and Zig has a policy to not accept AI assisted contributions, making it impossible for Anthropic to contribute to a language that is still evolving rapidly, not to mention the bad marketing of using a language that basically is hostile to your product.
CrimsonRain 3mo ago
A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. That somehow kills the project. ok!
- locknitpicker 3mo ago
  > A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. No,not really. There is only one point: does Bun acknowledge that past contributors still hold copyright over the Rust rewrite?

OJFord 3mo ago

Emphasis on the FOSS project. The v1.4 mentioned is not (yet?) open source, Claude Code is essentially using a proprietary fork, was GP's point.

goo0000fy 3mo ago
[flagged]
- OJFord 3mo ago
  From the article: > For me this outputs Bun v1.4.0 (macOS arm64). The most recent release of Bun on GitHub is currently v1.3.14 from May 12th, so that v1.4.0 version number in Claude supports them shipping a preview of a not-yet-released Bun version. Which is still true as I write this comment.
  - kelnos 3mo ago
    A charitable interpretation is that the version of bun inside Claude Code corresponds to some recent state of their public git repository, so if you clone that, you more or less get the same thing. I don't see what it would buy Anthropic to have some sort of secret internal fork with special private code in it.
    - goo0000fy 3mo ago
      bun upgrade --canary
  - simonw 3mo ago
    The code is on GitHub in the "main" branch, it's only unreleased in that it hasn't been tagged with a version number yet.
    - goo0000fy 3mo ago
      yeah the word "unreleased" makes it sound so mysterious i am a clankersceptic as much as the next guy and i hate "anthropic" for participating in the murder of innocent people (maven "smart" system, offers them as a provider to the pedo criminal unitedstatistan government) but this whole "unreleased" framing is just manufacturing drama / lack of knowledge

jeroenhd 3mo ago

My personal feelings about the matter is that having an LLM rewrite the entire thing as an experiment and then just going with it a few weeks later kills any incentive for a community to build up around it. It's a clear signal that every basic aspect of the runtime can change on a whim. I don't care about meh Zig being rewritten to bad Rust if it does the same thing, but taking what is presented as" look at this funny experiment I did" and then taking that into production with barely any announcement is what kills off the interest to me. Bun has been a great ad for whatever LLM they were using but the cool factor is gone now, and that's really what set it apart from basic NodeJS in my mind.

muglug 3mo ago
The language an application is authored in does not matter to me, as a user. I care that it is widely-used (safety in numbers), that it works, and that it is fast. It's cool that the Zig project exists, but I'm unlikely to ever use Zig so that’s sort of orthogonal to my interests.
atonse 3mo ago
Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers.
- jdiff 3mo ago
  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.
  - CrimsonRain 3mo ago
    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.

stymaar 3mo ago

Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared. “bun the JavaScript runtime ” is not dead though.

Matl 3mo ago
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
- Dylan16807 3mo ago
  Surely a lot of review has happened in the last two months?
  - endospore 3mo ago
    Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated. Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
    - Tadpole9181 3mo ago
      This feels like such an absurd, bad faith take I keep hearing. In Zig, every single memory operation is unsafe. And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors. There's too much, sure, but can we at least be honest and reasonable?
      - endospore 3mo ago
        My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it) > must interface with C code that has no safe interface Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2x as many unsafes. And mind you if you haven't read the code, the vast majority of unsafe blocks in bun are for raw pointer access to local (Rust) objects because their ownership was a mess both before and after the rewrite. Also funnily enough a lot of the access patterns are wrong (in the Rust sense), leading to hundreds of new undefined behaviors. > be honest and reasonable Well, well. Talking about dishonest and unreasonable behavior, why is bun releasing a new version before solving any of those glaring issues? I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.

hoppp 3mo ago

Bun is now mainly the runtime for claude code. All changes will go in to make claude code better. It's not about making the dev experience better than node, that use-case is now secondary.

amazingman 3mo ago

I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic.