13 ms·
Zig → Rust porting guide
- elnatro 5mo agoI don’t understand that effort. They could use Deno and be done with it.
- johalmed 4mo ago[flagged]
- deleted 4mo ago[deleted]
- punkbit 5mo agoI suspect that an experiment is being run. In any case, that'll be a hell of a story!
- yladiz 5mo agoWhy? Are there particular reasons that the maintainers of Bun feel the need to attempt to migrate from Zig to Rust?
- reissbaker 5mo agoProbably an experiment due to Bun's PRs to Zig being rejected (Zig does not allow AI use). If Rust works well enough, and the alternative is maintaining a fork of Zig, I'd guess they'd go with Rust.
- philwelch 5mo agoAlso, if Zig itself doesn’t accept AI contributions, it’s probably NGMI unless somebody is willing to maintain that fork.
- toshinoriyagi 5mo agoThe anti-AI policy had nothing to do with Bun's PRs being rejected. This post[0] by a core zig maintainer explains why the PRs were low quality and subsequently rejected. [0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19?u=badtuple https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
- andriamanitra 5mo agoWas there even a PR? The post from Bun [1] says they have no plan to upstream it, and that ziggit post says the changes are undesirable. It sounds like there never was anything to reject. [1] https://x.com/bunjavascript/status/2048428104893542781 https://x.com/bunjavascript/status/2048428104893542781
- _--__--__ 5mo agoPossibly related to https://simonwillison.net/2026/Apr/30/zig-anti-ai/ https://simonwillison.net/2026/Apr/30/zig-anti-ai/ where the Bun team wanted to upstream work to Zig that was rejected by a blanket anti-LLM contribution policy.
- kristoff_it 5mo agoCode origin was not even a factor https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
- _--__--__ 5mo agoThat seems totally reasonable but I wonder if there was some head butting in non-public channels given Bun is one of the biggest players in Zig and planned to push through a change like that on their own.
- croes 5mo agoI wonder if they didn’t consider the problems of their changes in Zig what else do they not consider in Bun
- kelnos 5mo agoEven if there was anything in private channels, the reasons stated in that forum post are alone more than enough to reject Bun's Zig changes.
- luma 5mo agoAnd also great reasons for Bun to port themselves elsewhere. If they aren’t allowed to contribute to Zig, there’s very little reason to select Zig moving forward.
- porridgeraisin 4mo agoIt's not that they were not allowed to contribute. If you read the ziggit link up thread it becomes clear why their solution was simply wrong.
- nikeee 5mo agoZig is a moving target that has breaking changes in every release (which is fine as they are sub-1.0). But that means that AI tools have been trained on outdated syntax/etc. Zig isn't that common, so there is even less training data to begin with. Rust on the other hand is pretty established by now and has less breaking changes. It also has more compile-time safety-guarantees that makes vibe-coding a bit more confident. In top of that, Zig has rejected their upstream contributions. So they'd have to maintain their own compiler in the long run, which is probably just technical debt to maintain.
- maxloh 4mo agoIs there even breaking change in Rust after 1.0?
- nullstyle 5mo agoMost of my vibe coding is in zig, and it has been my experience that Claude and Codex both keep up with zig changes just fine. Every now and then I catch them writing outdated code that they burn some tokens on, but my experience says your local codebases’s idioms will influence what gets generated enough to stop this from being a problem.
- sourcegrift 5mo ago[flagged]
- punkbit 5mo agoAbsolute nonsense. Why are you creating rumours?
- philwelch 5mo agoWhy would someone make up such a banal rumor? I’m not saying it’s true, I’m saying who cares?
- tipiirai 5mo agoReally? Do you have a source?
- philwelch 5mo agoNormal, emotionally stable people don’t care if the creators of a programming language disagree with them about tariffs.
- vips7L 5mo agoNormal, emotionally stable people don’t drive business towards people they disagree with politically. You see that all around the country.
- kelnos 5mo agoI can't find any evidence that the creators of Zig hold the views GP seems to suggest, but I think your assertion is wrong. Normal, emotionally stable people do sometimes make decisions about what businesses to patronize based on the political leanings of the business owners. Same thing happens with art appreciation, movie/TV watching, and plenty of other things. Zig might not be a business, but the same rules apply. You may think that's foolish, and not make your decisions that way, but it's a perfectly valid way to make decisions.
- 5mo ago
- tom_ 5mo agoIf the computer can do it for them, then why not?
- inkysigma 5mo agoSo I can't tell if the linked commit is an actual attempt or just an experiment but it did always strike me as odd to make a JS runtime in Zig when my impression was there were a lot of work-stopping compiler bugs at the time.
- ivanjermakov 5mo agoConsidering no public announcement this is just an experiment, possibly leaked.
- stingraycharles 5mo agoInteresting to see this when the current top post on HN is someone worrying about Bun as it was acquired by Anthropic. The top comment there describes “Anthropic does experiments on their own codebase, the Bun team is not gonna do the same vibe coding experiments”. Yet here we are, what looks like a massive undertaking for vibe coding. Time will tell how this will turn out. Would be nice if the Bun maintainers could give some clarification about what they’re doing here, and why they’re doing this.
- pstuart 5mo agoPorting from one typed language to another seems like a perfect use for LLMs. I can see the appeal of both languages and why to consider such an action (e.g., rust is a mainstream PL vs zig's cult status (no slight intended)).
- rtpg 5mo agoI think the big difficulty here is that Rust's ownership model in particular tends to require certain kinds of control flow to avoid a bunch of weird churning/copying, which makes it not as straightforward of a port target from other imperative languages. Like maybe you get the LLM to try _really hard_ to churn through everything, but this feels like a big case of "perils of the lack of laziness". Of course if you have a good idea for how to deal with allocations etc "idiomatically" already maybe that works out well. And to the credit of the port guide writer bun seems to have its explicit allocations that are already mapping pretty well to Rust.
- pstuart 5mo agoThis is all wild conjecture, but I'd assume that teaching the LLM to do that mapping is an achievable goal and then it get's close to automatic -- effectively slurp the source AST into a rust AST and render. My only experience with ports so far is Python to Go, and it's been near flawless (just enough stupid shit to make me feel justified to be in the loop).
- 5mo ago
- larpa 5mo ago"Claude, migrate bun to Rust, make no mistakes"
- 0x142857 5mo agoyou can use both zig and rust in a single project, duh
- psychoslave 5mo agoWe can even use all PLs in a single project. Starting question should go with something like "which part will we code rather in brainfuck and which in whitespace?"
- flykespice 5mo agomulti-language codebase are a nightmare to work with
- ConanRus 5mo agoinstead of writing it once in C++
- Humphrey 5mo agoI'll be very interested in how this AI port turns out. I am involved in a number of active projects that are being held back by the language / framework is holding back the project, but where a rewrite would be too big of a project to undertake by using only human power. I've had more success vibe coding Rust than I have in more dynamic languages. I suspect the strictness of the Rust compiler forces the AI agent to produce better code. Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job.
- rustybaritone 5mo agoYes it generates trash Rust code. > Not sure. It could be just that I am less familiar with Rust so it feels like it's doing a better job. Ya think?
- fgfarben 5mo agoDoy!
- moomoo11 5mo ago> It could be just that I am less familiar with Rust so it feels like it's doing a better job. Dunning Kruger effect. At least you admit it.
- raincole 5mo agoThis is pretty much the opposite of Dunning Kruger effect.
- deleted 4mo ago[deleted]
- jillesvangurp 5mo agoI've been targeting Go instead of Rust for a few things. But same deal, I'm not really a Go programmer and it seems to work well enough. I do have a few decades of engineering all sorts of code bases; so I'm not coming at this completely naively. My way of compensating for my own inability to do detailed code reviews is making sure the tests, integration tests, end to end tests, cover everything I care about. Without that, you can't be sure it is not skipping detail work. I've also made it do some bench marking and stress testing and then analyze the code base for potential bottlenecks. After it found and fixed a few issues, it got better. Finally, prompting it to do critical reviews, look for refactoring opportunities, etc. can give you a nice list of stuff to fix next. Having it run memory leak checkers and static code analysis tools also is a good strategy. Once you start running low on issues you find this way, the code is probably not horrible. Or at least you hit some sort of local optimum. The lack of code reviews sounds pretty horrible. But it is now quickly becoming the biggest bottleneck in AI assisted coding. Eliminating that bottleneck is scary but it enables a few step changes in volume of code that becomes possible. Using strict compilers and strict memory management helps eliminate a few categories of bugs and issues. I was previously doing this with languages I do understand. Once you start routinely dealing with larger and larger commits, reviews become a problem. I expect working with larger code bases like this will get a lot easier and better over time. I noticed that the main headaches I face with this type of engineering are the tendency of models to keep deliberately cutting corners, only doing happy path testing, or deferring essential work for later. I suspect a lot of the models are simply biased to conserving token usage. Pretty annoying but also easy to compensate for with follow up prompts and testing. And probably something that becomes less of an issue as the models get tuned to behave better without additional prompting.
- deleted 5mo ago[deleted]
- jr-14 5mo agoI want zig to succeed but given that zig is not yet 1.x I'd imagine a large code base like bun would have difficulties addressing major breaking changes. Also given the fact that bun is using a fork of zig https://x.com/bunjavascript/status/2048427636414923250?s=20 https://x.com/bunjavascript/status/2048427636414923250?s=20
- elffjs 5mo agoComparing this claude/phase-a-port branch with main: “Showing 1,646 changed files with 773,950 additions and 151 deletions.”
- jedisct1 5mo agoAnd of course, everything was carefully reviewed by a human.
- sergiotapia 5mo ago>*No `tokio`, `rayon`, `hyper`, `async-trait`, `futures`.* No `std::fs`, I'm not a rust dev but even I kind of notice that tokio is kind of shunned in most projects. Why is that? Is it just bad or what?
- allthetime 5mo agoYou shouldn't have to pull in big complex dependencies to do what should be primitive things. Zig is putting a strong and thought-out effort into getting async & parallelism "right" inside the stdlib. I'm honestly not up to speed with where rust is at with it at the moment, but last time I checked it was a bit of a mess.
- lstodd 5mo agoYou try to use it you'll get it. Otherwise it's just words. Like these: rust failed at async.
- Philpax 5mo agoIt's not really shunned - it's the standard solution for async in Rust - but it's not the right solution for every project, especially if you have specific requirements for how your project's computation should be scheduled. I would guess that Bun is one of those projects, especially as it needs to be able to schedule JS async work itself.
- dboreham 5mo agoAsync is an anti-pattern but sometimes inexperienced developers don't realize that and will infect your codebase with it.
- Philpax 5mo agoPlease explain.
- mmastrac 5mo agotokio is great and it's pretty performant, but you pay an allocation for every future unless you do some complex organization of your futures. Source: I worked on Deno, competed directly with Bun on HTTP performance (and won on some metrics). Edit: and of course I typed future instead of task (aka "spawned future"). Thanks, child commenters below. Much of Deno was built on spawning futures that mapped to promises and doing it as fast as possible. I spent ages writing a future arena to optimize this stuff..
- arthurcolle 5mo agoCould just be an experiment or something. It's Monday, the week is young
- nothinkjustai 5mo agoMakes sense on merit. There really isn’t room for Zig when Rust exists, is more ergonomic, and also safe.
- hbbio 5mo agoGiven they have "unlimited" AI usage, do we expect the port to be complete tomorrow?
- thayne 5mo agoWhen I first heard that bun was written in zig, I thought that was an odd choice for such a large project, mostly because the language is "unstable" and is still making significant breaking changes. I would guess dealing with breaking changes is a big motivation for this.
- archargelod 5mo agoLinked commit is probably not the most convincing for this tagline. Here's a branch[0] of Claude mass rewriting Zig code into Rust which is currently at 773,950 additions and 151 deletions: [0]: https://github.com/oven-sh/bun/compare/claude/phase-a-port https://github.com/oven-sh/bun/compare/claude/phase-a-port
- dsissitka 5mo agoI was curious how much work this would be. Here are the top five from cloc: ------------------------------------------------- Language files blank comment code ------------------------------------------------- Zig 1298 79693 60320 571814 TypeScript 2600 67434 115281 471122 JavaScript 4344 36947 37653 290873 C++ 583 27129 19117 215531 C 111 21577 83914 199576
- bastawhiz 5mo agoYikes. When Jarred left Stripe for the first time, he left behind multiple 10k+ line PRs rewriting code in the dashboard (this is before LLMs). It took months to work through those. A three quarter million line diff is essentially unreviewable.
- booleandilemma 5mo agoInteresting. When I thought of Zig, I thought of Bun. In my mind it was the flagship application for that language. Is there another? I wonder how the Zig team feels about this. To me it seems like Rust has definitively won now.
- hsaliak 5mo agoThe problem with vibe coded re-writes is that you basically sign off on understanding the generated codebase at that point. Any historical knowledge of the codebase is gone.
- noveltyaccount 5mo agoThis prompt defines the translation as a file for file, line for line port. Seems like historical knowledge will be fine.
- mr_00ff00 5mo agoHaving dabbled with both Zig and Rust, they do things so fundamentally differently, it isn’t possible to do exact lines like that.
- mswphd 5mo agothe rust they've written (so far) is highly unidiomatic (and with a ton of unsafe). I can't speak to the zig part, but it seems plausible to me it is line-by-line, horrendous rust. Whether or not they can clean it up is an interesting question.
- vintermann 5mo agoIf anyone can do it, it's Anthropic. The question is more how long it will take and how many tokens it will burn/how much groundwater.
- dathinab 5mo agozig can do some things wrt. compiler time compute which sits somewhere in between rust const expr and proc macro usage. This isn't something rust (or most languages) have. So even if we are generous and interpret line by line as expression by expression this isn't fully doable but also telling a LLM to do a line-by-line translation and giving it a file _is guaranteed to never truly be a line-by-line translation_ due to how LLMs work. But thats fine you don't tell it to do line-by-line to actually make it work line by line but to try to "convince" it to not do any of the things which are the opposite (like moving things largely around, completely rewriting components based on it "guessing" what it is supposed to do etc.). Or in other words it makes the result more likely to be behavior (incl. logic bug) compatible even through it doesn't do line-by-line. And that then allow you to fuzz the behavior for discrepancies in the initial step before doing any larger refactoring which may include bug fixes. Through tbh. I would prefer if any zip -> terrible rust part where done with a deterministic, reproducible, debug-able program instead of a LLM. The LLM then can be used to support incremental refactoring. But the initial "bad" transpilation is so much code that using an LLM there seems like an horror story, wrt. subtle hallucinations and similarr.
- kgeist 5mo agoInteresting how times have changed. Back in 2015, the entire Go runtime (already a mature codebase) was rewritten from C to Go semi-automatically: one of the maintainers wrote a C-to-Go conversion tool (for a subset of C they used) so that it compiled and produced identical output, and then the resulting code was manually refactored to make the Go code more idiomatic and optimized. And now you can just ask a language model. The slides: https://go.dev/talks/2015/gogo.slide#3 https://go.dev/talks/2015/gogo.slide#3 An interesting similarity: >We had our own C compiler just to compile the runtime. The Bun team maintain their own fork of Zig too
- kelnos 5mo agoThe big difference here is that the C-to-Go tool was presumably deterministic: running it over and over again should produce the exact same result. You can trust that result because the human wrote the conversion tool, understood it, tested it, and worked the bugs out. The LLM is non-deterministic. You could have it independently do the conversion 10 times, and you'd get 10 different results, and some of them might even be wildly different. There's no way to validate that without reviewing it fully, in its entirety, each time. That's not to say the human-written deterministic conversion tool is going to be perfect or infallible. But you can certainly build much more confidence with it than you can with the LLM.
- 0xpgm 5mo agoPerhaps a viable approach might be to vibe code the translation tool itself and observe that for every input it gives the expected output. Then once the translation is done, the translation tool can be discarded. This would require a robust test suite though. One of the cases where vibe coding might actually be useful, writing a throwaway tool.
- _vertigo 5mo agoI see this dilemma with LLMs all of the time. Should you use the LLM to do the thing directly, or use the LLM to implement a tool that does the thing? I tend to reach for the latter, it’s easier to reason about.
- Entambi 5mo agohahaha eat your heart out "don't port it to rust" gang
- sourcegrift 5mo ago[flagged]
- ratstew 5mo agoThis feels more like a reaction to Zig's anti-LLM policy than anything. Anthropic would probably like to contribute something back to Zig at some point, but I doubt anyone would ever believe their PRs were not written by Claude.
- lioeters 5mo agoExactly, this is a direct response to Zig refusing to accept pull requests from Bun (and Anthropic). That situation forced Bun to maintain a fork of Zig, and it makes sense in the long term that they'd rather port their entire project to Rust. I've really enjoyed Bun the past year or so, but the acquisition by Anthropic, Bun's codebase and documentation increasingly becoming AI slop, and this impulsive complete rewrite - all of it has ruined it for me and I'm actively moving off of Bun. I don't feel comfortable relying on it any longer.
- Capricorn2481 5mo agoZig said they wouldn't have accepted the changes without AI either.
- lioeters 5mo agoYou're right, I was just now reading the full explanation. https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... This makes me respect Zig team's stance more, that it's a technical decision more than an ideological one.
- deleted 5mo ago[deleted]
- root_axis 5mo agoAny confirmation that a genuine port is underway? This might just be an experiment.
- anymouse123456 5mo agoThis is a huge loss for the zig language and community. As a fan of the language, I hope it leads to some reflection on things that might need to change moving forward.
- Capricorn2481 5mo agoI think it reflects more on Bun. [1]. [1] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/19?u=andrewrk https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...
- Petersipoi 5mo agoBun is the largest project written in zig. And it isn't close. Bun is bigger than zig itself. Seems like zig isn't mature enough to handle Bun's needs, so I don't blame them at all for looking for off ramps. Only time will tell if rigidity from the zig team is worth the cost of losing Bun. It might be.
- toshinoriyagi 5mo agoZig won't be affected by Bun potentially moving to Rust, the language has been growing rapidly and one of the main proposals of Zig is "maintain it with Zig". It's ability to integrate with existing C code bases, as well as be a drop-in build replacement, has widespread use. In addition, the link in the comment you replied to explains why the PRs Bun opened to Zig would have lowered the quality of the compiler and how Zig has achieved even greater speedups, with more widely applicable features like incremental compilation and the self-hosted backend.
- kigiri 5mo agoIt is definitly worth it, and moving to rust because compile times are too slow ? This can't be the main reason for the switch
- anymouse123456 4mo ago
- cropcirclbureau 5mo agoThe only Bun shipped product I've used in anger is OpenCode and I regularly run into segfaults on it. I doubt this is the reason for migration but every time it happens, it reminds me the real cost of unsafe code. That being said, Zig is an absolute pleasure to write and I can't wait until it has a real library ecosystem, Rust's greatest boon.
- mswphd 5mo agothe rust port (at least currently) heavily uses unsafe as well https://github.com/oven-sh/bun/compare/claude/phase-a-port#diff-27db7fe365f3cf0d5338b002b8413e6ca0f47832fe59dca3fa51dd3e12468955 https://github.com/oven-sh/bun/compare/claude/phase-a-port#d... that isn't particularly surprising, but the point is I would expect getting things more stable than the zig version would take a bit.
- xiphias2 5mo agoThat's completely normal at the first step of the language transformation. Actually it's required if you do a file by file transformation first while wanting to maintain interface compatibility. I'm not sure I would take this kind of path, I would much more focus on refactoring the project to small and easily translatable components with small boundaries, but it's cheap to try things.
- ozgrakkurt 5mo agoHow do you even run it with bun? I get nodejs not found error when running opencode command in terminal. I installed it via bun too.
- peesem 5mo agotry `bunx --bun whateverthecommandis`?
- toledocavani 5mo agoFor better or for worse, at least Bun is open source, and the world is not lacking a NodeJS alternative. What is the most interesting here for me is: - a big, clear outcome and acceptance criteria, vibe coding project on - a public, working, high performance, full featured, production codebase by - the leading LLM model maker known for the strongest coding ability A good example no matter if it successes or not.
- confessinator 5mo agoAside from Zig's anti-AI stance and maintaining their own Zig fork, I think this port will showcase that Anthropic can re-engineer a massive codebase. As an aside, I've been bitten by Zig's breaking changes on my own projects as well. It's taken the shine off of Zig and I'm looking at alternatives.
- tacitusarc 5mo agoI wonder if a successful, albeit slower, approach would be to walk the git commit history in lockstep, applying the behavioral intent behind each commit. If they did this, I would be interested in knowing if they were able to skip certain bug fix commits because the Rust implementation sidestepped the problem.
- lll-o-lll 5mo agoInteresting idea
- efficax 5mo agothis is an interesting idea and i might try it with something smaller. there are more than 15,000 commits to bun, so you’d have to have some sort of way to operate on groups of commits in one prompt to get that done without thousands and thousands of api requests
- nicce 5mo agoMany segfaults in Bun issue tracker. I bet it would sidestep many.
- kajaktum 5mo agoWell…there would still be panics.
- dathinab 5mo agomost unsafe language to rust transpilations produce not just pretty terrible rust code but also use unsafe everywhere which is needed, as making things safe often requires refactoring not localized to a single function/code block and doing that while transpiling isn't the best idea. In general I would recommencement a non LLM based transpilation (if possible) and then use an LLM to do bit by bit as localized as possible bottom up refactoring to get ride of unsafe code potentially at some runtime performance cost, followed by another top down refactoring to make thing nice and fast. And human supervision to spot parts where paradigms clash so hard that you have to do some larger changes already during the bottom up step. anyways that means segfaults likely would stay segfaults in the initial transpilled version
- notnullorvoid 5mo agoProbably a good thing for the project even if the only net positive ends up being the Bun team stops maintaining a fork of Zig.
- Amber-chen 5mo ago[dead]
- y534y5 5mo ago[dead]
- classicposter 5mo agohttps://github.com/oven-sh/bun/issues/30197 https://github.com/oven-sh/bun/issues/30197 It seems there was an issue where the image API ignored the ICC Profile.(now fixed) Any developer with experience implementing image formats would almost certainly avoid this mistake. This is a problem that cannot be solved with vibe coding. In this situation, the user is merely a guinea pig for bug fixes.
- simonw 5mo ago... and that bug was spotted in the canary release, reported and fixed. Sounds like responsible open source software development to me. That's what pre-releases are for.
- Capricorn2481 5mo agoApril 26th - Bun announces they used AI to fork Zig so they could make an optimization for a 4x improvement April 27th - Zig contributor mlugg clarifies why the specific optimizations Bun did were ill advised and wouldn't have been accepted in Zig, regardless of AI use [1] May 4 - Bun is looking into Rust as an alternative. This, to me, seems like total whiplash. Has anyone at Bun made a statement on why they're making such dramatic changes? It seems like the lesson to internalize from mlugg is not "switch to Rust" [1] https://lobste.rs/s/ifcyr1/contributor_poker_zig_s_ai_ban#c_aaf9ga https://lobste.rs/s/ifcyr1/contributor_poker_zig_s_ai_ban#c_...
- baranul 4mo agoZig is a pre 1.0 language, subject to many breaking changes and has thousands of (stranded) issues on its GitHub. It was always a risky proposition to use Zig, unless those persons were philosophically committed to help the language develop or die-hard fans. If not, them jumping to some other language, should not be so big of a surprise. They may come to the conclusion that Zig is incapable of delivering on its promises or is deficient at satisfying their requirements.
- Capricorn2481 4mo ago> They may come to the conclusion that Zig is incapable of delivering on its promises or is deficient at satisfying their requirements Sure, but what you're suggesting is not related to the timeline I gave. They did not determine Zig was deficient in some way. They tried to get a cheap gain, and the gain breaks parts of Zig and they didn't even realize it, and it was worse than the gain already available in Zig. That seems less like they've made a pragmatic choice about speed and more like they are doing headline based development. What you write makes it sound like there's a pragmatic process being followed that only you are privy to, and I'd like to know what it is. Zig may be inappropriate for Bun after all, but this makes it look like they don't understand what they are doing, and the agentic coding doesn't help.
- baranul 4mo ago
- forrestthewoods 5mo agoI hope they ship and use this. It’ll be a super interesting case study in a few years.
- vga1 5mo agoIf they really started the work this week, we'll see by the end of June probably.
- classicposter 5mo agohttps://x.com/bunjavascript/status/1966806250827714736 https://x.com/bunjavascript/status/1966806250827714736 Haha, is it really okay not to retract that that the official account previously posted a caricature criticizing Rust?
- Petersipoi 5mo agoYes, it's quite ok to not "retract" a goofy image from months ago. It's harmless fun.
- Animats 5mo agoHow well does that long translation prompt work?
- hakrgrl 5mo agoPeople are asking why they would switch from zig to rust. I wonder the opposite: why would anyone would use zig over rust?
- vga1 5mo agoYeah, it's not clear. Especially the rise of LLMs is going to chip away Zig's strong points (simplicity at the cost of lesser safety) as time goes on. Which might be a part of why they're so stressed about it.
- wg0 5mo agoIf nothing, it'll be good marketing material targeted at non-technical enterprise executives so that they pressurize their engineering teams in meetings that look people are porting such complicated things from one different language to totally different language then why are we not using AI effectively?!
- matrix12 5mo agoit will make it more portable.
- ngoquocdat 5mo agoI think they are simply experimenting to fully exploit Claude's models' powerful capabilities.
- thatxliner 5mo agoDidn't they write a whole blog post on why they chose Zig over Rust?
- icase 5mo agooh for christ’s sake
- iamgopal 5mo agothe days are not far when golang will be ported to rust.
- lagniappe 5mo agoWatch your mouth.
- simultsop 5mo agoWhich makes one think, why they did not buy deno at first place then? If they did, I guess they would rewrite deno in C++
- AbuAssar 5mo agoI fully support this decision
- ivolimmen 5mo agoI am not a fan of AI but my limited experience with running local small LLM's did show me that rewriting some scripts into a different language worked really well. So my guess is this will just turn out fine.
- davidtranjs 5mo agothis isn't vibe coding. this is vibe rewriting. ~500k lines of code. nobody is reading those diffs line by line. nobody.
- GianFabien 5mo agoHere we go again ... Company A buys company B. A's management decrees the henceforth B's aqcuihired team must comply with company A's standards. Second system effect kicks in. Bugs multiply. Half of original company B devs leave. I'm investigating whether future projects should revert to using Deno.
- bijowo1676 5mo agoIts never been easier to rewrite X in Rust than today. Will everything eventually be rewritten in Rust and we finally achieve utopia?
- zelphirkalt 5mo ago... or will it all rust away? OK I'm sorry, I'll see myself out.
- vrighter 5mo agowhy would we need to rewrite twitter in rust? (sorry, couldn't resist)
- apatheticonion 5mo agoHaving written a JavaScript runtime in Rust in the past - Rust is an excellent choice. Not just due to the development experience, but also for embedders who want to consume the project as a a library (rather than a binary, e.g. node). Not sure about vibe-coding it. While they aren't using v8, LLMs made it easier to understand v8 quirks and update v8 as they make weird changes every now and then. It couldn't write the runtime without help though. For those curious: https://github.com/alshdavid/ion https://github.com/alshdavid/ion
- gib444 5mo ago> Read this whole document before writing any code. Hm does that actually work? Edit: in a way that can be verified, and not the AI tool saying it did
- joknoll 5mo agomaybe anthropic should‘ve just acquired deno
- padjo 5mo agoPicking a pre 1.0 language to build your product always seemed like a bad choice to me. Purely on that basis and ignoring the recent drama this seems like a reasonable idea for tech debt pay down to me. Assuming automated conversion can work without making things worse, which is not exactly a given.
- xigoi 5mo ago> Picking a pre 1.0 language to build your product always seemed like a bad choice to me. Such as React Native? :D
- yard2010 5mo agoYes. And don't get me wrong. I have made a living from it for years now. It's a wild ecosystem. Not for the faint hearted.
- padjo 5mo agoReact Native is only an application framework. Using a tool with an unstable API a level down the stack seems much worse. Foundations of sand is the phrase that springs to mind.
- esjeon 5mo agoPartially, the team would have never expected the project to be acquire before Bun touches v1.0.
- PKop 5mo agoOr, even if they 100% expected to be acquired before Bun touches 1.0, you could see how they might not care about this type of tech debt.
- hiroakiaizawa 5mo agoInteresting. What are the main trade-offs they expect from the switch?
- markovmodel 5mo agowhat a win
- rollulus 5mo agoRewriting it using an LLM is one. But did all the contributors became as proficient in Rust as they were in Zig over night as well?
- nananana9 5mo agoAlright, back to node. I was hopeful for this project, and I've reported crashes & bugs in the bundler with the hope that it will stabilize over time, but this is just silly - I'm not going to risk them pulling the rug under me and replacing the runtime with 1 million lines of vibecoded rust.
- selectnull 5mo agoWhy not rewrite claude-code in Rust? So, Anthropic acquires Bun team because claude-code uses Bun. They port Bun from Zig to Rust presumably because Rust "is better" (imagine big air quotes here). Again presumably, they want to make claude-code "better". Why make it so complicated? With all the power of LLMs they have, surely they can make claude-code the best possible by writting it in Rust directly.
- lionkor 5mo agoPresumably they aren't falling for their (extremely obvious) "grassroots" marketing, and know, like any good engineer, that LLMs are not the right tool for this. It's easy to just see Bun as a marketing stunt, as well.
- raincole 5mo ago> that LLMs are not the right tool for this. Claude Code itself is already heavily written by LLMs[0], so I'm not sure what's "this" here. You mean LLMs are okay for writing code but not porting? [0]: No, it's not just marketing. The codebase was leaked and anyone who glanced at it would realize the claim is likely true.
- CharlieDigital 5mo agoYou missed the point of the question: why write Bun in Rust when CC itself can be written in Rust ostensibly for even better perf.
- raincole 5mo agoAre you replying to the wrong comment? I clearly quoted which part I were replying to. I didn't attempt to answer the question "why write Bun in Rust when CC itself can be written in Rust." What I said is that "they know that LLMs are not the right tool for this" is not the answer, as CC is already vibecoded so it'd be very weird to believe you can't vibecode a port of CC. The actual answer is, of course, the whole discussion is just making a hill out of a mole. Bun is not committed to a Rust rewriting, vibed or not.
- lacymorrow 5mo ago[dead]
- kandros 5mo agoUnexpected, I was waiting for them to maintain a zig fork
- altun 5mo agoI guess it's like Trump saying, "I'll take Greenland too..."
- carpenecopinum 5mo agoGiven the recent gripe that Bun/Anthropic indicated regarding compile times with Zig (i.e. that their vibe-coded 4x compilation speedup PR wasn't accepted), it appears to me as an "interesting" move to switch to a language that probably delivers 4x longer compilations than even vanilla Zig.
- ozgrakkurt 5mo agoI am very sceptical zig actually compiles faster than rust. I had similar code written in zig and c++ and cold compilation was many times faster in c++ and incremental compilation was instant in c++. I think the reason most rust projects compile slow is because of excessive usage of dependencies and also the excessive use of metaprogramming in code. Zig doesn’t have multiple compilation units so it doesn’t parallelize compilation
- kristoff_it 5mo agoYou might be interested in learning more about `-fincremental`, that's how Zig gives you fast rebuilds.
- kadhirvelm 5mo agoI can't imagine going from reviewing code in Zig to letting Claude code handle it in Rust. Seems like a lot of change to deal with in a short amount of time. Wonder how much the bun team culture will change? We've been really liking bun so far
- croemer 5mo agoAt this point, it looks just like an experiment. It's not a definitive "were going to switch". I think people here are reading too much into it.
- holysantamaria 5mo agoMaybe Mythos told them to quit using zig because it is not safe
- dmytrish 5mo agoYou don't need Mythos for that, just open the bun issue tracker and filter for "segmentation fault".
- deleted 5mo ago[deleted]
- Jarred 5mo agoI work on Bun and this is my branch This whole thread is an overreaction. 302 comments about code that does not work. We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. I’m curious to see what a working version of this looks, what it feels like, how it performs and if/how hard it’d be to get it to pass Bun’s test suite and be maintainable. I’d like to be able to compare a viable Rust version and a Zig version side by side.
- vga1 4mo agoMight be a good idea to let AI handle social media. I'm not saying you're doing it badly, just that it doesn't seem like worth the drained energy to do manually.
- jorisw 4mo agoCan't think of a more stupid and detrimental way to use AI. Pretending to be a (particular) human on social media.
- hellohello2 4mo agoYou can view it as an overreaction, but also as a sign that your work is significant. It impressed some, and scared others. In any case, you made something interesting.
- hn_throwaway_99 4mo agoYou're replying to the original author of Bun. Given the usage of Bun, and the fact that his company (primarily him, actually) was recently acquired by Anthropic for what I'm guessing was a bajillion dollars, I think he probably already knows his work is significant and that he made something interesting.
- hellohello2 4mo agoLol! My bad, I wasn't aware it was the original author (my fault for replying with too little reading). In any case, I think what I said still applies to his LLM experiment.
- _pdp_ 5mo agoClaude Mythos cannot do the porting?
- jvidalv 5mo agoBun can't be used for anything serious, only as a "script kiddie" to run small scripts. Trying to run it as a replacement for node in persistent backend/api scenarios is just plain broken. RSS grows unbounded under Bun: https://discord.com/channels/876711213126520882/1480589657983942696 https://discord.com/channels/876711213126520882/148058965798...
- born-jre 5mo agoLet the guy cook, would be nice benchmark of llm nothing else. Damn I wish I had access to infinite tokens for crazy experiments like this.
- deleted 5mo ago[deleted]
- mohsen1 5mo agoI am also porting TypeScript to Rust. With a different design I managed to make it faster than tsgo port. I've made a lot of progress in the last 4 months but needs more work. Contributions are welcome! https://tsz.dev https://tsz.dev
- ale 4mo agoThe fact that tsz can compile to wasm might actually give you an even more interesting feature that tsgo can't (yet): using the type checker for data validation at runtime.
- ozgrakkurt 5mo agoJust checking some loc numbers from nodejs, bun and deno: On nodejs: `tokei src`: 98333 LOC C++ Code On bun: `tokei src` 573572 LOC Zig Code On deno: `tokei libs cli runtime` 289573 LOC Rust Code This seems wrong though so would be appreciated if someone who knows the structure of these projects can correct me on the folder names. Doing `tokei lib src test deps` gives more than 5M loc. but not sure if that is fair
- shevy-java 5mo agoPoor Zig - it's bleeding now. Everyone wants to be a Rustee these days.
- insumanth 5mo ago[dead]
- noborutakahashi 5mo ago[dead]
- asG1298 5mo agoI mean this is self-evident. Bun got bought by Anthropic to shill in the open source space: https://bun.com/blog/bun-joins-anthropic https://bun.com/blog/bun-joins-anthropic "I got obsessed with Claude Code" So the bad, bad Zig that opposes the clanker mania has to be punished, even if top comments deny it. Anthropic is one of the most evil companies in existence today. Whenever someone produces something, they steal it.
- jgalt212 5mo agoThat PORTING.md file is massive and seemingly comprehensive. Was that AI written as well? Is there a general Zig to Rust porting template being used?
- grougnax 5mo agoGreat. Everyone should use Rust.
- dividendflow 5mo ago[dead]
- hiccuphippo 5mo agoI wonder if something like Haxe, a language that was able to transpile to several languages would be the best target for LLMs. They could always generate haxe and then transpile it to whatever language the user wants. Probably not for an already ongoing project like this but for a greenfield one.
- RedsonNgwira 5mo ago[flagged]
- potsandpans 5mo ago@dang: is this the kind of curious conversation that you're cultivating?
- arunc 5mo agoJust curious, why Go was not an option. TS compiler was rewritten in Go.
- pjs_ 5mo agoSo far the wonders of claude/codex have been mostly constrained to applications that are built within the boundary conditions of existing libraries -- the models make direct use of the good work that humans have done to date to build Python, `requests`, `ffmpeg`, you name it. But I'm excited for the (I think inevitable) stage where the shoggoth starts to reach outside those constraints -- rewriting, patching, renaming, rebuilding libraries, DLLs, binaries -- and we move into a regime where the libraries dissolve, the application floats on top of the shifting sands of an ever more efficient, secure, unified and totally inhuman technology stack. Obviously this is a horrifying idea in some ways (interpretability, security etc), but it's also not obvious to me that it can't work, especially if there are dedicated, centralized efforts to do this. it's also not clear that interpretability is necessarily mutually exclusive with full slopification/machine rewrite of decades of foundational, incremental development
- frankfrank13 5mo agothis makes me so scared to work on OOS. If people saw every random draft PR, branch, design doc I ever made, no doubt the community would be furious
- gosukiwi 5mo agoBun is showing their lack of experience and guidance
- deleted 5mo ago[deleted]