| |
| ▲ | atonse a day ago | parent | next [-] | | 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. | | |
| ▲ | jasode a day ago | parent | next [-] | | >Literally who cares what language a JS toolset is written in? Maybe you're being coy by asking a rhetorical question you already know the answer to but I'll answer as if you asked sincerely... There are 2 different groups interacting with software products: (1) end-users : this is where the "Who cares what language it's written in?!?" is usually applicable. E.g. The finance guys using MS Excel don't care whether it's written in assembly, BASIC, or C Language. (2) code contributors and/or programming language enthusiasts who see other projects as "validation" of the whatever language they've invested in: these people definitely care. For all the decades that computer languages have been debated, Group (2) will always discuss projects language choices. E.g. reddit.com switching from Lisp to Python, the Linux kernel fiercely debating future Rust contributions , the Typescript compiler switching from Javascript to Go, Bun switching from Zig to Rust, etc. People try to lecture others in Group 2 about "don't make a programming language your identity" ... but people are human and they can't look at all the above language choices as totally detached observers. They like to talk about it! If one is a Zig coder that contributed to the previous Bun Zig codebase, we can't expect them to be neutral observers. | | |
| ▲ | estearum a day ago | parent | next [-] | | I think you're missing group 3, which is the "assume bad faith and/or bad outcome from any possible change to anything, and especially changes to open source projects that can be interpreted as exogenous, e.g. from an acquirer, and especially if that acquirer is a gigantic commercial entity." There are not nearly enough disenfranchised Bun-on-Zig contributors to make a dent in this conversation. There are lots of Group 3s in every similar convo, for any combination of technology, project, and acquirer you can name. | | |
| ▲ | atonse a day ago | parent [-] | | I think most of the naysayers are in group 3 because there’s a lot of anger but never a single link to a blog post or analysis done by anyone to demonstrate a regression. not one. There are some that analyzed the quality of the initial rust code and use of unsafe but Claude has been chewing through those as I understand. | | |
| ▲ | simonw a day ago | parent | next [-] | | I thought that too but it looks like the usage of unsafe hasn't been trending down over time: https://news.ycombinator.com/item?id=48966569#48967630 | |
| ▲ | endospore 8 hours ago | parent | prev | next [-] | | https://github.com/oven-sh/bun/issues/30719#issuecomment-446... Personally I chose not to disclose my findings in public to avoid this kind of outcome. Having a good laugh with others is not as important as keeping the result of this experiment undisturbed. This also eliminates the chance of another round of marketing of LLM ability based on actual human contributions and I suggest everyone who is able to analyze the code to do the same - so that they cannot misattribute our ability to LLMs. | |
| ▲ | ksec a day ago | parent | prev [-] | | It was a PR issue more than anything else. It is also a proxy for Pro AI and Anti AI sentiment. And for most part I don't think it was communicated well apart from the last blog post. |
|
| |
| ▲ | rjzzleep a day ago | parent | prev [-] | | What about Group x. You just AI generated 1 millions lines of code claiming it's for safety. Who exactly is to make any kind of security guarantees about this? | | |
| ▲ | tokioyoyo a day ago | parent | next [-] | | What was your safety guarantee pre-rewrite? If CVE scanners and aggregators is your answer, then well, this applies to post-rewrite as well. | |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | conartist6 a day ago | parent | prev [-] | | Don't forget the group asking really dumb pointless questions like "who legally owns the rewritten code" | | |
| ▲ | ethbr1 a day ago | parent [-] | | Afaik, under current US law (Thaler v. Perlmutter 2025^), "the Copyright Act of 1976 requires all eligible work to be authored in the first instance by a human being". With regards to AI-generated code, this means the copyrightability (at all, not with regard to who owns it) turns on whether or not a human was substantially involved in its creation. Existing decisions require evidence of pretty heavy and continued human guidance to qualify.+ To wit, autonomous agent created code (prompt -> machine churns for hours -> output) is explicitly not eligible for copyright. Functionally, this is a double-edged sword. On the one hand, it means anything coded with autonomous agents by Meta, Google, et al. can be legally reused if it leaks (because no one could hold copyright on it). On the other hand, it leaves copy-left open source licenses in a weird place. If you convert open source (even MIT/BSD-style) code into something else with an autonomous coding agent... the result has no copyright (nor can ever in the US). In this instance, Bun was MIT-licensed, no? Then it was shoved mostly-autonomously through an LLM for the port. Now Bun-Rust is technically still MIT licensed, but if push came to shove it seems like US law's current position is that Bun-Rust would now have no copyright license (because the manner in which it was developed renders it ineligible for copyright). That's on the copyright side. On the infringing usage side (i.e. whether you were entitled to shove a copyrighted work into a coding agent to produce something)... that's still TBD. ^ https://media.cadc.uscourts.gov/opinions/docs/2025/03/23-523... + https://garrettham.com/ai-generated-works-copyright/ | | |
| ▲ | eventhorizon77 a day ago | parent [-] | | Couldn't it be argued that Bun-Rust is still MIT licensed, because the old implementation was "in the first instance" authored by a human? All the machine did was translate it. I think it's the "infringing usage" question that is more interesting. If the LLM trained on GPL-derived code, what does that mean for the end result? | | |
| ▲ | simonw 21 hours ago | parent | next [-] | | "If the LLM trained on GPL-derived code, what does that mean for the end result?" Either it means nothing at all, or it means that a substantial portion of the code produced at some of the world's most valuable companies over the last two and a half years is GPL. | |
| ▲ | conartist6 19 hours ago | parent | prev [-] | | Yeah you could argue that, but it's a messy argument. I'm wiling to imagine that they hadn't used AI to do the rewrite to Rust. It wouldn't have been all that hard to do with plain old syntax tree transformation (my expertise). The trickier question for me is the ownership at the boundary where prompts were turned into Zig code. That is not a process that could have been done with syntax tree transformation: creative freedom was given to the model as to how to do the work at that stage, and so that is the stage at which I'm least sure they could legally defend their claim to ownership. | | |
| ▲ | ethbr1 7 hours ago | parent [-] | | I feel like that's a lot of LLM use in a nutshell: sure, there's a more surgical scalpel available, but isn't it so much easier just to fling prompts at a magic box? |
|
|
|
|
|
| |
| ▲ | layer8 a day ago | parent | prev | next [-] | | > who cares what language a JS toolset is written in? Anthropic, apparently, not the least because they blanket-closed all issues submitted before the rewrite. If the language were irrelevant, it shouldn’t matter for the existing unfixed issues. | | |
| ▲ | pronik 21 hours ago | parent | next [-] | | > blanket-closed all issues submitted before the rewrite You'll need a citation for that. While I'm still not sure whether Claude Code's issue tracker is worth much (Anthropic doesn't seem to engage with individual issues a while lot), it still has 5k+ open issues ranging back to March 2025. Bun also still has all of its Zig-timeline issues, all 5k+ of them. So what's this about? | |
| ▲ | skybrian a day ago | parent | prev | next [-] | | [dead] | |
| ▲ | doctorpangloss a day ago | parent | prev | next [-] | | imagine being the leadership of the one of most valuable US private companies in the world. then you have to make something called a "pull request" that gets "reviewed" by someone named "Jarred" to make improvements to your stuff. do you see how that is untenable? the language is relevant for political not technical reasons. you could say, blanket closing the Issues, getting rid of this thing called Jarred from your stack, etc., is really an attack on the GitHub and the GitHub Agitator Lifestyles, which is why so many commenters on Hacker News actually care. | |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
| |
| ▲ | jgalt212 a day ago | parent | prev | next [-] | | > It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. This is even more interesting given that prewar Bun was not a well respected code base. This matters if the code was bad, were the tests bad / not comprehensive as well? If so, the translation to rust whose sole / primary target was test-passing will have a fair amount of undocumented bugs in it. > poster child for Zig programming language actually being the prime example of How Not To Write Zig Code https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht... | | |
| ▲ | NewsaHackO 11 hours ago | parent [-] | | Did he say this opinion before the rewrite, or when he was taking tens of thousands of Bun's money per month? |
| |
| ▲ | queenkjuul 3 hours ago | parent | prev | next [-] | | >It’s made absolutely no negative difference, as we’ve seen in the real world in the last 60 days since the merge. The rust code is not yet in a stable release, and CC only switched to it in the latest version, so there's not been 60 days of widespread battle testing yet, so i don't see how we could possibly say it will have no negative difference. It hasn't, because nobody is using it yet. It still might. >Literally who cares what language a JS toolset is written in? I don't care what language it's in, but i do care how it is written and maintained. I'm not going to trust my projects to a runtime that was written by an LLM in two weeks with practically no human review | |
| ▲ | re-thc a day ago | parent | prev | next [-] | | > that this made bun worse in any measurable way Issues on GitHub was mass closed claiming zig is no longer relevant without fixing the real issues. | | |
| ▲ | atonse a day ago | parent [-] | | Whole classes of bugs WERE fixed by moving to rust. wouldn’t that result in mass closures of classes of bugs that were no longer relevant in rust? What would you prefer? | | |
| ▲ | jdiff 15 hours ago | parent | next [-] | | Whole classes of bugs are fixed by safe rust. This is not safe rust. As a line-by-line translation with unsafe forced anywhere necessary to make it compile, this should result in no classes of bugs fixed by moving to rust. | |
| ▲ | re-thc a day ago | parent | prev [-] | | I would prefer they confirm before closing. It's AI / bot anyway. Instead it's just mass keyword zig = close. The bug can still exist post-port. None of it got "fact-checked". In fact a lot of "feature requests" like npm compatibility related or missing specs etc ALL also got closed for being "zig" because reproduction and suggested solution were of course zig. Again doesn't mean it got "auto fixed". |
|
| |
| ▲ | bbg2401 a day ago | parent | prev | next [-] | | The crux is: > What is the governance structure for Bun by the way? Couldn't find any documents/explanations about how it's supposed to work. I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today? And this is a valid question. You are not "defending reality" by refusing to listen to it. In summary and based solely on my understanding: - Jared misled people about the intentions of the migration. It's not the worst thing in the world, but it's certainly worthy of criticism. - Jared has commented before about locking out human contributors from open source projects. Whether he was making a larger point is irrelevant as his comment stands on its own. - Other Bun contributors, past and future, outside of those employed by Anthropic, did not and likely will not have equal access to the model Jared used for the rewrite. Jared, working in the public Bun repository, used tooling not available to his community to experiment with a signficant migration. He dismissed all concerns and told people it's just a bit of fun, and that it shouldn't be taken seriously. Most of the controversy would have been avoided were the experiment done in private. None of this is a big scandal but questions about the project are entirely justified. | | |
| ▲ | cube00 a day ago | parent | next [-] | | > I'm guessing it's essentially just "Anthropic decides what gets done and accepted" today? Similar to the Claude Code 60s timeout incident [1] it could just be "Jarade decides what gets done and accepted" [1]: https://news.ycombinator.com/item?id=48949942 | |
| ▲ | Grombobulous a day ago | parent | prev [-] | | Sometimes the questions aren't justified, though, like when someone else’s project is someone else’s project. It seems like when some folks see “open source” they think the project maintainers owe them something. An open source MIT license of the source code is very different from being the original copyright holder. |
| |
| ▲ | zzzeek a day ago | parent | prev | next [-] | | this whole AI era has put the topic of "do we believe actual reality, or what we hoped/assumed/continue to insist would be reality" front and center. Every discussion is like this these days. | |
| ▲ | bmitc a day ago | parent | prev | next [-] | | The outrage was more how the rewrite was communicated and defended, which was objectively poor. | | |
| ▲ | pronik 21 hours ago | parent [-] | | Which was completely bonkers -- it happened completely in the open, people were just outraged that something like this happens without asking them and not on a schedule they perceive as adequate. Most of them haven't really grasped what was happening and why. Many still don't. | | |
| ▲ | cube00 18 hours ago | parent | next [-] | | > it happened completely in the open You don't create PRs like this when you're working "completely in the open" test ci #30412
No description provided.
https://web.archive.org/web/20260509235415/https://github.co... | | |
| ▲ | tick_tock_tick 15 hours ago | parent [-] | | You don't test CI before you publish stuff? | | |
| ▲ | cube00 13 hours ago | parent [-] | | I give the PR a proper title on creation. I don't see any reason to create a PR with a title of "test ci" and then rename it later to: Rewrite Bun in Rust #30412
|
|
| |
| ▲ | bmitc 19 hours ago | parent | prev [-] | | It wasn't out in the open. It was never announced or discussed ahead of time. It was just done because the company who purchased Bun wanted it done, and they only communicated it was happening once they started. I don't consider the following comment to be good, honest, and open communication: https://news.ycombinator.com/item?id=48016880#48019226 | | |
| ▲ | 18 hours ago | parent | next [-] | | [deleted] | |
| ▲ | simonw 19 hours ago | parent | prev [-] | | What was dishonest about that comment? > There’s a very high chance all this code gets thrown out completely. ... and a few days later he decided that the code wouldn't get thrown out. That doesn't make the comment itself dishonest, he didn't have a crystal ball. You can absolutely argue that the rewrite was not communicated clearly once they committed to it, but I don't think the comment you linked to there stands as evidence of poor communication at the time it was written. | | |
| ▲ | bmitc 18 hours ago | parent [-] | | He knew he wasn't going to throw out the code when he made that comment. | | |
|
|
|
| |
| ▲ | vermilingua a day ago | parent | prev | next [-] | | Except that it hasn’t yet hit the real world, the live release is still 1.13.4, the last Zig version. Anthropic does not operate in the real world. | | |
| ▲ | Tadpole9181 a day ago | parent [-] | | The canary build has been Rust for over a month, available to anyone. In that time it has been used in production for Claude Code and Prisma Compute. | | |
| |
| ▲ | well_ackshually a day ago | parent | prev [-] | | [flagged] | | |
| ▲ | CrimsonRain a day ago | parent [-] | | 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 > 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 a day ago | parent [-] | | > v140 is the canary version which has been available for a long time. 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? | | |
| ▲ | simonw a day ago | parent [-] | | Yeah, it looks like they constantly repoint the "canary" tag at whatever they think should be the new canary release. I don't like that, personally. I think the project would be easier to reason about if they shipped alpha versions instead. | | |
|
|
|
| |
| ▲ | stymaar a day ago | parent | prev | next [-] | | 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 a day ago | parent | next [-] | | 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). | | |
| ▲ | rane a day ago | parent | next [-] | | "Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising. | | |
| ▲ | endospore a day ago | parent [-] | | "Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process. Can't help laughing at this point. | | |
| ▲ | mpyne a day ago | parent | next [-] | | I don't know, did the prior vibe-coded Zig code not ever have pointers aliased to data? Might be preserving semantics too well, if anything. | | |
| ▲ | endospore a day ago | parent [-] | | The Zig one uses raw pointers. These are bad and get out of hand quickly but at least don't have constraints like "you must never have two &mut on the same value". You may refer to c2rust to see how "semantics preserving transformation" without new UBs looks like. |
| |
| ▲ | pylotlight 11 hours ago | parent | prev [-] | | You didn't read the blog post at all did you? Clearly you have zero clue what you are talking about. | | |
| ▲ | endospore 10 hours ago | parent [-] | | Sorry, I did. And I did an internal sharing with respect to the blog post, on topics of how to (and not to) do software migration, how (not) to deal with unknown unknowns etc. We have several ongoing software (automated) migration projects so I did rather extensive research around it. I do regret that I've also read the code though, otherwise I'd probably live a little happier with ignorance right now. Sadly as they don't know they don't know about the issues, there's no indication of those in the two public materials they have released. |
|
|
| |
| ▲ | uecker a day ago | parent | prev | next [-] | | Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic. | |
| ▲ | Dylan16807 a day ago | parent | prev [-] | | Surely a lot of review has happened in the last two months? | | |
| ▲ | endospore a day ago | parent [-] | | 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 a day ago | parent [-] | | 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? | | |
| ▲ | ambicapter a day ago | parent | next [-] | | What's the point of rewriting it to Rust if you're going to, on purpose, disable the most prominent benefits of using Rust? | | |
| ▲ | Tadpole9181 a day ago | parent | next [-] | | It isn't disabled, it has exclusions. Now that they have it, they can close the gaps. It was literally impossible to have ANY coverage before, now they are mostly, covered and have an avenue for remediation. I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good? Was nobody here for moving billions of lines of JavaScript to Typescript? It starts with declarations, then turn on type checking gradually inside the codebase: piece by piece until done. | | |
| ▲ | fleventynine 21 hours ago | parent [-] | | I like Rust and use it full-time professionally. Unsafe is not the same as unsound. Unsound means that the unsafe code is not maintaining the aliasing invariants on references required by the language, and thus undefined behavior can leak into safe code (that is, the safe code can be miscompiled). Known unsound code should not be merged, let alone released to production. If you have good enough tests and run them under MIRI or ASAN, maybe you can get away with it for a time, but most Rust experts would not sign-off on such a project. If somebody put a gun to my head and told me to make the best of such a codebase, I would try to figure out how to turn off the LLVM optimizations that assume the Rust references don't alias. With these optimizations this codebase is scarier than most C or C++ code. |
| |
| ▲ | skydhash a day ago | parent | prev [-] | | I'm not a rust dev. But I've been once asked to take care of a TypeScript codebase and the thing was littered with so many casts to `any`, you're wondering why they bothered with TypeScript in the first place. Some people do choose tech on a vibe and not any real analysis. |
| |
| ▲ | endospore a day ago | parent | prev [-] | | 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. | | |
| ▲ | lunar_mycroft 21 hours ago | parent | next [-] | | > Deno for instance have ~0.2x as many unsafes. Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code). | |
| ▲ | Tadpole9181 a day ago | parent | prev [-] | | > I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability. Except, you know, multiple real companies saying that it is and using it in production. And the fact it closed all known memory leaks. And that nobody has a really pointed to a single actual issue the new version introduced after two months of endless, ceaseless bitching. I'm also fascinated by all these people upset at Jarred for harming the readability of a codebase they've literally never cared about before it become drama. Bun has almost exclusively been maintained by Oven employees since it's inception. > Deno for instance have ~0.2x as many unsafes. A project written ground-up in Rust idiomatically, with a smaller surface area, still has an unsafe footprint within an order of magnitude compared to this automated rewrite from an unsafe language with different practices and known bugs? That's not exactly the slam you think it is. | | |
| ▲ | endospore 18 hours ago | parent [-] | | > nobody has really pointed to a single actual issue I personally know 3 categories of newly introduced issues spanning the code base with 200+ occurrences, that leads to undefined behavior and memory issues. Not doing any contributions to the code is my conscious decision, which includes not pointing to the specific problems in public. It's nice to hear that people are doing the same. |
|
|
|
|
|
| |
| ▲ | ljm a day ago | parent | prev | next [-] | | > bun was vibe coded by a single dude without any open source community involvement. I think even this is largely beside the point. The acquisition of any project by Big Capital (whether tech or VC) is usually a killing blow. | |
| ▲ | Dylan16807 a day ago | parent | prev | next [-] | | Is the idea that a code base reset makes something stop being open source? Or that the number of people doing the reset matters? I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language. | | |
| ▲ | avianlyric a day ago | parent [-] | | I think the point is that an “open source project” is more than just the code and license, it’s also the community that builds and maintains it. A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again. | | |
| ▲ | Tadpole9181 a day ago | parent | next [-] | | Just so everyone know, Bun is and has always been owned by a YC funded org with full time employees. The overwhelming majority of commits came from them. | |
| ▲ | Dylan16807 a day ago | parent | prev [-] | | A reset is very different from not being open source any more. If losing most of the community would mark a project dead in open source terms, then every new project would be dead on arrival. And that would just be silly. |
|
| |
| ▲ | CrimsonRain a day ago | parent | prev [-] | | That's just like your opinion...? More power to Jared (and anyone else) if they can "vibe code" useful projects like bun. |
| |
| ▲ | _pdp_ a day ago | parent | prev | next [-] | | 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 a day ago | parent | next [-] | | 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 a day ago | parent | next [-] | | 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 a day ago | parent | next [-] | | 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. | | |
| ▲ | pmarreck 3 hours ago | parent | next [-] | | I guess that since you haven't built the car you're driving, your opinions on it are null and void as well. Anyone who actually believes that I can't have ANY sound opinion on Zig after 31 projects building with it should get their head examined for brain tumors. I mean, it's not like I have to deal with all the positive and negative effects of things written in it. It's not like I've had to solve problems in it that emerged when the LLM didn't do things correctly (and yes, I can tell when this is so, and not just when things are buggy). And it's not like I don't know (by heart, not by LLM) at least 15 other languages that I can draw on (C, for example, for which I not only got an A in a class at Cornell once, but was in fact the person with the highest score in a class of ~150 people... A perfect score, in fact) to form valid opinions in combination with how I see Zig working. So please take your baseless skepticism and baseless assumptions and shove them up your ass, dude. I have work to do, and I'm far more capable of it now than I was, thanks to the LLM boost. | | |
| ▲ | 59nadir an hour ago | parent [-] | | Honestly, I wasn't harsh enough... Though I don't think I could write a better post showing how useless your opinion on things actually is than the one you wrote yourself. And no, I don't think you can have any valuable opinions on Zig since you don't write it. In your analogy you're not even driving the car, but it doesn't surprise me that you can't figure that out. |
| |
| ▲ | lstodd a day ago | parent | prev [-] | | 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 a day ago | parent | next [-] | | 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. | |
| ▲ | pmarreck 3 hours ago | parent | prev [-] | | Same. In fact I think going to Zig, possibly on the way to Rust, would have been a far more pragmatic route. But I guess my opinion is null and void since I "slop-code" |
|
| |
| ▲ | pjmlp a day ago | parent | prev [-] | | Industry standards, existing team knowledge, use after free story is the same as C already has. |
| |
| ▲ | casey2 9 hours ago | parent | prev | next [-] | | Bun was the flagship product of zig? In reality or in YC land | |
| ▲ | bitwize a day ago | parent | prev [-] | | Zig is a DOA language for other reasons though. The reason why Rust enthusiasts act so morally superior is because they are: > Rob Pike, an unsafe guy, may insist that a small language and garbage collection are enough. But the typesafe visionary Grzegorz Wielbodłąński understands the deeper truth: every invalid state permitted by a compiler is a tiny act of civilizational sabotage. https://x.com/typememetics/status/2078572052680790237 There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. Rust is so thoroughly and obviously the correct thing that using anything less correct should be taken as a sign of engineering incompetence. | | |
| ▲ | K0nserv a day ago | parent | next [-] | | > There is no sense pretending anymore that languages with as many gotchas as C and Zig are "simple". Quite simply, they are not. The complexities lie in what's left unspoken, unaddressed, and of course undefined; failure to comprehend these completely can be catastrophic. This is where I’ve arrived too. After nearly 20 years of programming I feel done with leaving foot guns lying around. Languages that are full of them, but “fine” as long as you take extreme care are not interesting to me. I’ve started calling this “simple as long as you avoid all the foot guns” idea the sword juggling fallacy[0]. It’s too bad about Zig because it has many nice ideas, in particular allocators, that I hope Rust or some future language will adopt. 0: https://hugotunius.se/2026/06/15/the-sword-juggling-fallacy.... | | |
| ▲ | dnautics a day ago | parent | next [-] | | yeah rust has no footguns. just dont try to mix clone with iter. | | |
| ▲ | K0nserv a day ago | parent [-] | | Of course Rust has a few footguns too, that's not my point. |
| |
| ▲ | skydhash a day ago | parent | prev [-] | | There are many things in life that are "fine" only when you take extreme care (knives, cars, industrial machinery,...). The thing is something like C has many usages and you can't just say "use Rust" and be done with it. Using Rust is not cost-free. | | |
| ▲ | K0nserv a day ago | parent [-] | | I'm not saying "never use C". The thing I dislike is the false dichotomy between "(Zig|C|Go) is simple unlike Rust, which is complex". A statement like that makes it sound like writing correct code in the former is easier when it's, in fact harder. | | |
| ▲ | dnautics 15 hours ago | parent [-] | | the thing is, as a pattern, footguns in zig are simple and easy to reason about (though they might be hard for an ADHD human to find). the compositional nature of rust sometimes makes footguns "hard to see" because they can be hidden behind layers of abstraction. there is a potential future where an llm with unbounded patience would have an easy time literally walking through the zig code looking for one of the footguns might miss a footgun in rust because it's abstracted away. the ones in the stdlib should give you pause. what is hiding in some third party library's code? |
|
|
| |
| ▲ | pjmlp a day ago | parent | prev | next [-] | | There is more to it even, the UNIX and C founders arrived to Go, before retirement, after a few other interactions. AT&T was the one doing the Cyclone research. And then we have a bunch of folks assuming they know better about C that its own authors? | | |
| ▲ | BigTTYGothGF a day ago | parent [-] | | > And then we have a bunch of folks assuming they know better about C that its own authors? Barthes aside, C's changed a lot in the years since they left. | | |
| ▲ | pjmlp 20 hours ago | parent [-] | | Yes they stopped caring after C89, Plan 9 C compiler was a mix of C89 with extensions. Still they are the authors, and withdrawing from WG14, going their own direction with Alef, Limbo, and finally Go, kind of proves the point they considered C done for its original purpose. | | |
| ▲ | BigTTYGothGF 17 hours ago | parent [-] | | > kind of proves the point I don't think it proves anything other than the wanted to work on something else. | | |
| ▲ | pjmlp 13 hours ago | parent [-] | | It is a bit of presumptuous for one to assume to know better about something than the original authors. Something was designed in a certain way, accomplished its goal of writing portable UNIX, and then design by committee took over. The authors, with their experience moved on, the committee and the audience doubled down on the flaws. |
|
|
|
| |
| ▲ | csb6 19 hours ago | parent | prev | next [-] | | The post you linked to seems to jump to conclusions, to say the least. For example: > One probable outcome of an unsafe-language-dominant world is full Andrew communism, which is precisely what Andrew “Smelley” Kelley proposes: abolish ICE and replace the market economy with a globally distributed network of community-maintained allocators. > Rather than a commercial product, software becomes a “public good,” ultimately provided by the Zig Software Foundation as manually managed digital infrastructure. Calling him "smelley"? Really? Pulling in the political views of the founder of a language and claiming that they inform his language design as part of a grand conspiracy against Rust/capitalism? Where are they getting all of this? Free, open-source compilers and related tooling (both of which Rust and Zig have) are already public goods managed by global communities of mostly volunteers > This future strikes me as a dystopian hellscape, but I have never met an unsafe-language advocate who could explain how this ecosystem is supposed to sustain itself without unpaid maintainers, ideological volunteers, subsidized infrastructure, and endless donations to compiler projects that still cannot protect users from basic memory errors. How is Rust any different than Zig in this respect? Both are projects largely run by nonprofits relying on communities to promote, maintain, and improve them. Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues. | | |
| ▲ | pseudony 12 hours ago | parent | next [-] | | > run by genuinely insane people who think type and memory safety are paramount societal issues So. Rust evangelists ? :) But yes, it is wild that people can honestly quote such drivel as evidence of the language and its philosophy being superior. Each time I try to evaluate Rust, I do so on its own merits. Going online I am rapidly convinced that I don’t want to be in the same room as a large chunk of its userbase. Statements start to sound a bit like that one time I was dragged into a pentecostal meeting. | | | |
| ▲ | Ygg2 10 hours ago | parent | prev [-] | | > Calling him "smelley"? Turnabout is fair play. > Frankly, that entire "Institute for Type Safe Memetic Research" seems like either an elaborate satire or an account run by genuinely insane people who think type and memory safety are paramount societal issues. You've been had. Your entire rant means the bait worked. |
| |
| ▲ | Ygg2 12 hours ago | parent | prev [-] | | You didn't just quote The Institute of Typesafe Memetic Research as proof of anything... It's a shitposting, hyperbolic bait account. As funny as calling Andrew Kelley Smelley, it's not meant to be taken as gospel. |
|
| |
| ▲ | phoghed a day ago | parent | prev | next [-] | | If this were true the very small but active community of Zig contributors could just fork it and you could all return to the happy times of not using Bun anyway. | |
| ▲ | CrimsonRain a day ago | parent | prev [-] | | Bun became a thing because it provided some specific benefit to js ecosystem. Zig enabled the rapid development. The people who contributed were definitely helpful but they can still choose to help or not and new people will step up too | | |
| ▲ | LtWorf 10 hours ago | parent [-] | | > new people will step up too Or they will not… how could you possibly know. |
|
| |
| ▲ | OJFord a day ago | parent | prev | next [-] | | 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. | | |
| ▲ | sorenbs 6 hours ago | parent | next [-] | | It's a canary releasing directly from main: https://github.com/oven-sh/bun We have run it in production for a month: https://www.prisma.io/blog/bun-rust-rewrite-prisma-compute | |
| ▲ | atonse a day ago | parent | prev | next [-] | | You can install it now we with bun upgrade —-canary it something along those lines. | | |
| ▲ | NuclearPM a day ago | parent [-] | | I think you’re missing a word or two. | | |
| ▲ | layer8 a day ago | parent | next [-] | | Based on comments elsethread, I think what was meant is: You can install it now with “bun upgrade --canary”, or something along those lines. However, people also report that the canary version doesn’t identify itself as version 1.4. | | | |
| ▲ | OJFord a day ago | parent | prev [-] | | It's extremely obvious what they meant, even if it/or wasn't a common phone autocorrect typo. |
|
| |
| ▲ | CrimsonRain a day ago | parent | prev | next [-] | | And GP is full of shit as the main branch is the v1.4.0. it is not "released" yet as it is not finished. It is available as canary version. | | |
| ▲ | croes a day ago | parent [-] | | So Anthropic ships with unfinished version of bun. Doesn’t sound like responsible software deployment | | |
| ▲ | CrimsonRain 17 hours ago | parent | next [-] | | They can ship with whatever they want as long as it works. | | |
| ▲ | croes 15 hours ago | parent [-] | | Given the permissions Claude Code gets on many systems they should be more professional. They are basically testing the rust port on user machines. Who come that since the rise of AI all principles of software development are thrown over board? |
| |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | a day ago | parent | prev [-] | | [deleted] |
|
| |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | goo0000fy a day ago | parent | prev [-] | | [flagged] | | |
| ▲ | OJFord a day ago | parent [-] | | 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. | | |
| ▲ | simonw a day ago | parent | next [-] | | 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. | | |
| ▲ | OJFord a day ago | parent | next [-] | | If it hasn't been tagged with a version yet, how do you know (or what makes you think) it's the same as this 'v1.4'? | | |
| ▲ | simonw a day ago | parent [-] | | I don't know for certain, but it seems likely that it is given that Jarred said "Claude Code v2.1.181 (released June 17th) and later use the Rust port of Bun". What motive could he have for secretly maintaining a private fork of Bun that's shipped with Claude Code while simultaneously working on the open source repairs every day? |
| |
| ▲ | goo0000fy a day ago | parent | prev [-] | | 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 |
| |
| ▲ | kelnos a day ago | parent | prev [-] | | 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. | | |
|
|
| |
| ▲ | hoppp a day ago | parent | prev | next [-] | | 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. | |
| ▲ | afavour a day ago | parent | prev | next [-] | | 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. | | |
| ▲ | kstenerud a day ago | parent | next [-] | | Why is that even a thing to object to? You're talking as if you placed stock in the bizarre idea that Anthropic would close source the project and start charging for it. Stay your pitchforks. | | |
| ▲ | afavour a day ago | parent | next [-] | | I wouldn’t use language as strong as OPs but it is against the spirit of FOSS for a corporate owner to use a private prerelease version of their open source software. I think it’s valid to object to. If 1.4 is good enough to be used by Claude, why not us? | | |
| ▲ | kstenerud a day ago | parent [-] | | So you wouldn't, for example, after doing a complete ground-up rewrite, perhaps spend a few months dogfooding it to work out the worst bugs before unleashing it upon the public, thus maximizing your initial velocity by minimizing the blast radius and support requests and triage during this phase? | | |
| ▲ | realo a day ago | parent | next [-] | | It's Anthropic. I am pretty sure they spent time dogfooding it to Mythos or an even more advanced model. That might even be the reason why they switched to rust. Don't worry too much. | |
| ▲ | afavour a day ago | parent | prev [-] | | > before unleashing it upon the public …but they have? Claude users are public, no? If they were dogfooding internally I’d agree with you. | | |
| ▲ | kstenerud a day ago | parent [-] | | Yeah. One single project that they control. Not thousands of other people's projects breaking, I'm sure with a ton of HN outcry over releasing "this pile of vibe coded slop" upon the poor populace. You just can't win. | | |
| ▲ | afavour a day ago | parent [-] | | > you just can’t win You could! You could not release a “pile of vibe coded slop” onto people’s machines. There don’t even appear to be any particular advantages to Claude upgrading early. If there are no one has been made aware of it. | | |
| ▲ | ithkuil a day ago | parent | next [-] | | The irony. A company building models and tooling to automatically produce code being attacked for using automatically produced code in the very tools that allow people to automatically produce code, presumably by somebody who wants to use their tools to automatically produce code, possibly because they believe that their approach at ensuring that automatically produced code is properly reviewed by a responsible human has to be more thorough than whatever that company does because of course they were going too fast and thus it can't be good | |
| ▲ | kstenerud a day ago | parent | prev [-] | | How do you know it's vibe coded slop? Have you seen the source code? | | |
| ▲ | ethbr1 a day ago | parent [-] | | > How do you know it's vibe coded slop? Have you seen the source code? I believe you've just made your opponent's point for them. | | |
| ▲ | kstenerud a day ago | parent [-] | | Have I? I believe I've merely chased them around their moving goalposts. When it's closed source, that's nefarious because "they're not sharing" and that's against the whole spirit of open source. When it's dogfooding with a reduced audience, it's "shoving vibe coded slop on people" (this information gleaned through magical knowledge). When that unfounded assertion is called, lo and behold: It's closed source, so bad bad bad! It's called a logical fallacy for a reason. But more to your point: Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code? | | |
| ▲ | ethbr1 a day ago | parent [-] | | More to the point, because you've been chasing them around goalposts, you've both accepted that the question at hand is unknowable precisely because the source isn't available. > Do you believe in "guilty until proven innocent"? Do you believe that they're doing bad things with the bun code, and you can't be convinced otherwise in your judgment of them until they release the code? Hell yes, and anyone who trusts one of the AI labs for anything important is insane. Whether it's their initial mass piracy and then lying about it, dealmaking with the US government, or continually shifting opt-out lines on what they are and aren't training on, they haven't earned the trust to skip the "but verify" step. Their economic incentives are too transparently aligned with ends at any costs. |
|
|
|
|
|
|
|
| |
| ▲ | well_ackshually a day ago | parent | prev [-] | | You're running a closed source piece of software (claude code), running on an effectively closed source piece of software (bun), both of them updated daily by AI psychosis bros. At this point, charging is the least of your issues. |
| |
| ▲ | kelnos a day ago | parent | prev | next [-] | | It may be available to us, in the form of a git checkout of their public repository. It's true that we don't know exactly which, and whether or not there are any other changes added on, but that is the case for every single release of Claude Code that has used bun. | | |
| ▲ | dgacmu a day ago | parent [-] | | It's probably not. I tried to extract the commit hash from the version of bun packaged in claude code. the commit hashes from previous versions resolve, whereas the commit hash for the current 1.4.0 isn't available. from strings: bun-v1.4.0
f6d0fcd24abd48061873c2f1a6fb2a67eee487b8
Upgraded.
Welcome to Bun's latest canary build!
This build does have a different way of identifying itself than earlier builds so it's possible this string isn't correct.(In contrast, earlier builds that I have locally have commit IDs that can be found in the public repo). I don't think it's particularly damning for them to vendor a canary release, mind you. |
| |
| ▲ | jen20 a day ago | parent | prev | next [-] | | That is also true of the rest of their codebase, no? | |
| ▲ | firesteelrain a day ago | parent | prev [-] | | Moving the goalposts? | | |
| ▲ | afavour a day ago | parent [-] | | 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 a day ago | parent [-] | | > 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 a day ago | parent | next [-] | | 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 a day ago | parent [-] | | 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. | | |
| ▲ | afavour a day ago | parent | next [-] | | I think your perception of events is pretty heavily affected by personal bias here. Objecting to a hasty AI rewrite of an entire runtime and objecting to violating the spirit of FOSS is “very social justice warrior”? What? | | |
| ▲ | firesteelrain a day ago | parent [-] | | Please re read your original comment. AI rewrite is one thing and objecting to FOSS/non FOSS is a new argument, anti-Anthropic etc is moving the goal posts. The main argument was the blanket rewrite to Rust using Claude. Now, /you/ are trying to move the goalposts into an entirely different argument. Very likely it’s just anti Anthropic altogether. Like I said, a meme. Anthropic hasn’t done anything wrong but if they move a single inch then people will complain. Perhaps it is just a preview version? | | |
| ▲ | afavour a day ago | parent [-] | | Airing two entirely separate objections to a project is not “moving the goalposts”. The original objection still stands! You’re using a phrase you’ve heard in an inappropriate context. I’m sorry but this is a nonsensical debate. > Now, /you/ are trying to move the goalposts into an entirely different argument. You said something and I responded to it. That’s invalid too now? There can only ever be one single objection in a conversation? I’m not permitted to react to the things said? Like I said, nonsense. | | |
|
| |
| ▲ | NewsaHackO 8 hours ago | parent | prev [-] | | People are now saying poor communication because the Bun creator was not able to see the future and didn’t immediately flag his draft rewrite as the next big thing when he started working on it. |
|
| |
| ▲ | embedding-shape a day ago | parent | prev [-] | | > 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. I'm just one person though, and have no problem with a move to language X, using tool Y, who cares? For "goalpost are being moved" to be valid here, you have to be able to point to someone saying one thing at one point, then same person putting a different target later. You're folding a huge group of people into one person, when that's not really accurate to do. | | |
| ▲ | firesteelrain a day ago | parent [-] | | https://news.ycombinator.com/item?id=48843352 https://news.ycombinator.com/item?id=48837877 | | |
| ▲ | embedding-shape a day ago | parent [-] | | Your point being? None of my comments in either of those state that I'm upset about it moving from Zig to Rust? | | |
| ▲ | firesteelrain a day ago | parent [-] | | I wasn’t referring to you and rather the general sentiment. Hence, goal posts have been moved again comment. | | |
| ▲ | embedding-shape a day ago | parent [-] | | My overall larger point (maybe poorly stated) was that unless you're engaged specifically in a 1-on-1 conversation with someone, accusing a whole community of "moving the goalpost" makes no sense, there is a whole host of arguments and points being made in different directions all the time, by different individuals. | | |
| ▲ | firesteelrain a day ago | parent [-] | | I see what you are saying. My comment is rooted in the fact that different people are foregrounding different objections to Anthropic/Bun, and taken together it looks like whatever launches, someone will find a reason to be upset | | |
| ▲ | LtWorf 10 hours ago | parent [-] | | Maybe you should consider the objections by their merit rather than just being angry someone dares to criticise anthropic? | | |
| ▲ | firesteelrain 7 hours ago | parent [-] | | Already did, a few comments up. Happy to go through specific objections again if useful. This particular comment was about thread-level dynamics, not a verdict on any one objection’s merit. |
|
|
|
|
|
|
|
|
|
|
| |
| ▲ | Cthulhu_ a day ago | parent | prev | next [-] | | 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). | | |
| ▲ | flohofwoe a day ago | parent | next [-] | | 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), 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 a day ago | parent [-] | | 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 a day ago | parent | next [-] | | Are you really "doing things securely" when you use as many unsafe blocks as the Rust port of Bun does? | |
| ▲ | LtWorf 10 hours ago | parent | prev [-] | | 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. |
|
| |
| ▲ | gipp a day ago | parent | prev [-] | | 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. |
| |
| ▲ | pjmlp a day ago | parent | prev | next [-] | | 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. | |
| ▲ | foxes a day ago | parent | prev | next [-] | | 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 a day ago | parent [-] | | > 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. |
| |
| ▲ | amazingman a day ago | parent | prev | next [-] | | I didn't read OP as complaining about the rewrite, but about the (lack of clear) governance after being acquired by Anthropic. | |
| ▲ | a day ago | parent | prev | next [-] | | [deleted] | |
| ▲ | jeroenhd a day ago | parent | prev | next [-] | | 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. | | |
| ▲ | entrope a day ago | parent | next [-] | | > taking that into production with barely any announcement is what kills off the interest to me. Did Bun v1.4.0 release weeks ago and I missed it? I would call a formal release the point that it goes "into production", and I think dogfooding it via Claude Code is yet another form of testing Bun-in-Rust before the latter goes to casual users. | | | |
| ▲ | atonse a day ago | parent | prev | next [-] | | Which community specifically though? The overwhelming “user” community would be web developers and people writing JS/TS, right? Not zig/rust developers. | | |
| ▲ | jdiff a day ago | parent | next [-] | | 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 a day ago | parent [-] | | 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. | | |
| ▲ | jdiff a day ago | parent [-] | | 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. | | |
| ▲ | CrimsonRain 17 hours ago | parent [-] | | 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. | | |
| ▲ | jdiff 16 hours ago | parent [-] | | 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. |
|
|
|
| |
| ▲ | waisbrot a day ago | parent | prev [-] | | 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. |
| |
| ▲ | hibikir a day ago | parent | prev | next [-] | | It's like a couple of languages I know where there's still one real owner, and there's no real review, and PRs are unlikely to be merged, even with review: They might be open source, but it's more a source visible thing, because you are never going to get a change in, and the language will change directions at the creator's lone whim. The best you can get at times is "I didn't like your PR, so I implemented the feature you tried to add completely different". Typical community killers. | |
| ▲ | muglug a day ago | parent | prev [-] | | 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. |
| |
| ▲ | locknitpicker a day ago | parent | prev | next [-] | | > 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. | | |
| ▲ | brabel a day ago | parent | next [-] | | > 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 a day ago | parent | prev | next [-] | | A lot of hypotheticals, conjecture, speculation, personal feels devoid of any facts. That somehow kills the project. ok! | | |
| ▲ | locknitpicker 6 hours ago | parent [-] | | > 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? |
| |
| ▲ | conartist6 a day ago | parent | prev [-] | | of course they also gave away their own claim to be the copyright owner, but that's neither here nor there ; ) |
| |
| ▲ | embedding-shape a day ago | parent | prev [-] | | 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 a day ago | parent [-] | | 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 | | |
| ▲ | embedding-shape a day ago | parent | next [-] | | > The whole point of the outrage Ok, go ask those people what they think then, I feel no outrage over a project switching language or merging whatever. But when once-semi-transparent projects become more opaque after an acquisition, I'm starting to readjust anything to the project I had in mind. | |
| ▲ | jdiff a day ago | parent | prev [-] | | 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 a day ago | parent | next [-] | | It's publicly available in the GitHub repository and if you run "bun upgrade --canary" - https://github.com/oven-sh/bun/releases/tag/canary | | |
| ▲ | jdiff a day ago | parent [-] | | 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 a day ago | parent [-] | | I think Bun/Anthropic should document which commit hash their "1.4" as shipped in Claude Code uses. |
|
| |
| ▲ | alexjurkiewicz a day ago | parent | prev [-] | | Come on, "not publicly available"? You know how git works right? Each Claude release probably has the HEAD of main compiled as "1.4.0" until there is a real official release. | | |
| ▲ | queenkjuul 2 hours ago | parent | next [-] | | The commit hash reported by "1.4" doesn't exist in the public repo | |
| ▲ | jdiff a day ago | parent | prev [-] | | I do know how git works and in my experience, while the version number sometimes doesn't get bumped until just before a release is tagged, the version number comes from the codebase. If they're building something that says 1.4.0, then they have a codebase that disagrees with ours. | | |
| ▲ | Lerc a day ago | parent [-] | | Where is the previous version referred to in the codebase? I'm guessing that would be the place to look for changes. If you can't find an update at that place in the codebase saying 1.4.0 you can ask where it is. It seems after doing that and not receiving an answer would be the appropriate time to start making the claims that people are throwing around. This seems like a candidate https://github.com/oven-sh/bun/commit/b18bf6d1d0a92238f240bf... |
|
|
|
|
|
|
