20 ms·

Bun's experimental Rust rewrite hits 99.8% test compatibility on Linux x64 glibc

• punkbit 5mo ago
  An update on Bun’s experimental migration from Zig to Rust: The Rust rewrite now passes 99.8% of Bun’s pre-existing Linux x64 glibc test suite.
• rvz 5mo ago
  [flagged]
  • vintagedave 5mo ago
    > absolute position of hating something such as AI and progress Most takes I've seen are far more nuanced. Key is that 'progress' has a positive connotation. It is different from change. Mere change - such as new inventions - may not necessarily be aligned with progress in a field, society, etc. Change may be inevitable, but it's up to us humans to sculpt it into progress.
    • rvz 5mo ago
      But I am talking about Zig and others who have the same stance. Zig has a very strict No LLM / AI contribution policy and it likely got in the way of the Bun maintainers at Anthropic. From [0] >> No LLMs for issues. >> No LLMs for patches / pull requests. >> No LLMs for comments on the bug tracker, including translation. [0] https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy https://codeberg.org/ziglang/zig#strict-no-llm-no-ai-policy
      • vintagedave 5mo ago
        They don't hate it. There's no antagonism that I know of there. I believe they want it to be fully human-authored and want low-hanging fruit items to be good onboarding for developers, not targeted by AI contributions. Simon Willison wrote a good blog post on it: https://simonwillison.net/2026/Apr/30/zig-anti-ai/ https://simonwillison.net/2026/Apr/30/zig-anti-ai/ The Bun pull request was refused for additional reasons: 'AI is entirely beside the point here...': 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... None of this is, in the original comment's text, "hating... AI".
        • merlindru 5mo ago
          how do you square that with the "no LLM translators" rule? i agree i dont think they hate LLMs but that one seems unreasonable and odd, and makes me wonder if its ideological after all
  • punkbit 5mo ago
    Thats true, but the author might have decided on its own. Not everything is a marketing plan.
• aurareturn 5mo ago
  6 days of work to do this. Even if it doesn't end up becoming meaningful, it shows just how tokens and work done will be linked now and in the future. It's going to be hard to compete with someone or a company that has more compute. They will just be able to do things you can't.
  • pjmlp 5mo ago
    With less employees....
    • aurareturn 5mo ago
      Isn’t just one guy?
      • Defletter 5mo ago
        Exactly
        • rvz 5mo ago
          This is exactly how Anthropic will market this rewrite towards companies thinking about doing more layoffs. 1 person did a rust rewrite that took 6 days that would have taken hundreds of engineers more than a year to do.
          • baq 5mo ago
            The saving grace here is a rewrite of a project with a good test suite is the sweet spot: LLMs are great at translation and do great with verifiable goals. I agree it’s still mind blowing compared to before times, though.
          • xienze 5mo ago
            > 1 person did a rust rewrite that took 6 days that would have taken hundreds of engineers more than a year to do. Even cheaper would just be to not do it in the first place. Was there a pressing need to rewrite it?
• black_13 5mo ago
  [dead]
• anilgulecha 5mo ago
  I think the industry is moving to English as the programming language, and specifications-context-tdd as the framework for building software. Many find it distasteful, and many finding liberating. I think it's broadly correlates with how they feel about expressing themselves in english vs say C++. As a side question, is there anyone who's using LLMs primarily in non-english mode to program? I suspect there's quite a few people using mandarin, but can someone share first-hand account.
  • SwiftyBug 5mo ago
    I wonder how well Mandarin works for LLM-based programming. On one hand, it's very token efficient as Mandarin script is very dense in meaning. On the other, I suppose this can increase ambiguity.
    • jamesdutc 5mo ago
      I can speak, read, and write Taiwanese Mandarin (which is likely relatively underrepresented in the training sets and, which is, in my practical experience, materially different in its usage.) The authoritative answer for this question would best come from the millions (or tens of millions) of Chinese-speakers who are currently using LLMs to write software. However, it is my suspicion that you would see no advantages using any language other than English. While there is a certain token-level density to written texts, it seems the benefits of this (and the more recent discussion around “caveman talk”) are quite limited. Furthermore, consider that the vast majority of textbooks, technical documentation, blog posts, StackOverflow answers, &c. are originally in English. Historically, where these have been translated to Chinese, the translations have often been of very poor quality (and the terminology and phraseology is often incomprehensible unless you also understand some English.) I would suspect that this makes up the overwhelming majority of the training sets for these models. That said, my experience using the most recent models, is that they are surprisingly language-agnostic in a way that surpasses readily-available human capability. For example, I can prompt the LLM to translate English into something that uses German grammar, Chinese vocabulary, and Japanese characters, and I'll get an output that is worse than what a human expert could do… but where am I going to find a multilingual expert? (Of course, I have so far only ever been impressed that a model could generate an output but never impressed with the output it did generate. Everything—translations, prose, code—seems universally sloppy and bland and muddy.) So what I would anticipate the biggest benefit for a Chinese-speaker today… is that if they are disinterested in working internationally, they have significantly less dependency on learning English.
• lousken 5mo ago
  Good enough for a side project, not good enough for transferring banking system from cobol
  • jaytaph 5mo ago
    Why not? I think we are perfectly capable on generating a test and validation environment that we can use for correctness. Most likely llms could do this better than engineers with zero to none domain and language knowledge can do these days. From that point on, rewrites would become feasable (not easy, feasable).
  • pjmlp 5mo ago
    That is actually what companies like IBM and Unisys are already doing today, LLM assisted porting. https://research.ibm.com/publications/enterprise-scale-cobol-to-java-translation-llms-augmented-with-program-analysis https://research.ibm.com/publications/enterprise-scale-cobol...
• spicyusername 5mo ago
  What a time to be alive. So much of the fundamental dynamics of the industry and the job have changed in so little time. Basically over night. Some days I am so excited at how much I can do now. You can build anything you want, in basically no time! 100% of my software dreams can be a reality. Some days I am terrified at what's going to happen to the job market. Suddenly you can get so much with so little. The world only needs so much software. Is every company that sells software as their core business model going to go out of business? What will happen if only certain companies or governments get access to the best models?
  • wolttam 5mo ago
    Certainly companies and governments will have access to better models than the public (in fact, that's already the case with Mythos). The public will still be able to help themselves with models that are behind the frontier.
    • zurfer 5mo ago
      Maybe, or they use the same smartphones as everybody else. The mass market also wants the best model and will pay accordingly.
  • keeda 5mo ago
    > The world only needs so much software. Around the time of the dot com crash, there was a decent amount of rhetoric advising students and job seekers against getting into the software industry, because it was getting "too saturated." The thinking was there's just not that much work to go around, especially for the number of people flocking to the field. And the crash just reinforced that narrative. But even as a student back then, I could tell that there was unlimited scope for software. Pretty much any cognitive thing we do manually could be done in software. I once idly tried to enumerate those and quickly realized there was soooo much to do. Plus, I also understood that the more you do things a new way, a lot more things pop up that we haven't even imagined yet. The possibilities were countless. It was clear that the "saturation" narrative stemmed from a lack of people's imagination and understanding of what software really was. I just knew that this field would never get saturated because it was impossible to run out of things to write software for. But these days... I mean, I know we will always have new software to build as things evolve, which they will do faster than ever with AI. But these days, I wonder if it's now possible to write software faster than we can imagine new things to do.
• pulsartwin 5mo ago
  At the very least, it's interesting to be a bystander observering as efforts like this progress. The first thing it makes me wonder is how comprehensive/high quality the test suite is to begin with. Not to cast aspersions, but even at 100% on all platforms I wonder how confident the Bun team would be in migrating.
• m4rtink 5mo ago
  What license is this ? Let me guess, its is no GPL...
  • scared_together 5mo ago
    Unlike the GNU coreutils rewrite in Rust, the Bun rewrite in Rust is being undertaken by the owners of the project. That said, yes, you’re correct that Bun isn’t GPL: https://github.com/oven-sh/bun?tab=License-1-ov-file https://github.com/oven-sh/bun?tab=License-1-ov-file
    • m4rtink 5mo ago
      Hmm, that's unfortunate - why does so much Rust stuff seem to default to MIT/BSD ? Just because Mozilla used that for most of the Rust stuff ? Do developers using Rust even know the difference ? Like how anyone can basically take all you work & base a proprietary fork on it with maybe saying "thanks" (attribution) if they feel like it ? :P
      • conradludgate 5mo ago
        I'm very aware when I pick Apache-2. I want attribution for my work, but I don't care about open source purity. I respect closed source software and I put my open source code up for free because I don't care to profit off of my hobbies.
      • johnny22 5mo ago
        for the same reason most ruby and javascript/typescript stuff is. Heck, even most python. Most of them never got into the GPL in the first place.
      • bob001 5mo ago
        > Like how anyone can basically take all you work & base a proprietary fork on it with maybe saying "thanks" (attribution) if they feel like it ? :P I'd assume the Bun people got a bit more than a thanks when Anthropic acquired them. :) You also can't take your GPL code (unless you do CLAs with all contributors), convert it to closed source yourself and make a massive VC funded startup around it. Which is about the only other way anyone makes better money from open source than by just working for a big tech company.
• 0-bad-sectors 5mo ago
  Interesting! I wonder how the performance is compared to the Zig version
• ksec 5mo ago
  I think a lot of people taking this at face value , a lot of this was possible because of the beyond standard extensive and comprehensive test suit previously built.
  • scuff3d 5mo ago
    Look what it can do in 6 days! Ignore the hundreds of thousands of hours put into the original architecture and test suite that made it possible in the first place.
    • cmrdporcupine 5mo ago
      Exactly this. I am not sure why people sound so astounded, to be honest. This has been my frank experience of the agentic tools both Codex and Claude since about December. When given the right constraints this kind of thing is entirely conceivable. However the important question not being answered here is: does anybody working on it have a full understanding of what has been built? My experience having constructed similar types of projects using these tools is yes, you could do this in a week or two but now you'll have a month or two of digging through what it made, understanding what was built, and undoing critical yolo leaps of faith it made that you didn't want.
      • scuff3d 5mo ago
        Not to mention to even attempt something like this from scratch would take hundreds of hours if spec work. I see it all day everyday in the aerospace sector. Software engineers have absolutely no idea what deriving a design document and all its associated artifacts actually looks like, and they're in for a rude surprise if the industry really does shift hard that direction
    • zaptheimpaler 5mo ago
      This is such a bad faith argument. How long would it take a dev or a team of devs to do this with the same architecture and test suite? A hell of a lot longer than 6 days..
• akagusu 5mo ago
  What does this mean for Zig? Few big popular projects use Zig, if they start to move away from it, what Zig's future will look like?
  • jadbox 5mo ago
    Jarred has already said on Twitter that this was only an experiment for comparisons and very, very unlikely that they'd switch to Rust.
    • __s 5mo ago
      https://news.ycombinator.com/item?id=48077663 https://news.ycombinator.com/item?id=48077663
  • SwellJoe 5mo ago
    It means nothing for Zig. Zig isn't even out of beta yet.
  • NewsaHackO 5mo ago
    I think the issue is that Zig lost their biggest project, which was a posterboy project for real uses of Zig. Worse, the project felt like Zig wasn't meeting their needs, to the point they abandoned Zig and rewrote their entire project in a different language. Really bad signal for anyone thinking of using Zig for a big project. It is still in beta, but has there been any situation like this, where a upcoming programming language was abandoned by its biggest external project and still was able to be considered a successful language after that?
    • toshinoriyagi 5mo ago
      Well they haven't lost anything yet. Somebody is vibe coding a rewrite in another language and we don't know much else. The author said he will write a blog post about it soon. So far all we know is it is passing most of the test suite. But Bun has open issues and bugs. The test suite doesn't tell us whether it has introduced many new bugs, solved existing ones the test suite doesn't catch, or anything else. Not to mention, the rewrite is 960K lines that nobody understands. How long will it take for the Rust version to be better, and be understood as well as its current maintainers understand the Zig version? Having a project consider a rewrite isn't so big a deal. Zig has been designed from the ground up with a vision, and isn't worried about taking a while to create a stable API to achieve that vision. The self-hosted backend shows how incredibly fast incremental compilation is when the language is built for it ground-up. Compared to other languages that implement weaker forms of incremental compilation it isn't even close. I don't think the Zig team is concerned at all.
• rererereferred 5mo ago
  The branch in question: https://github.com/oven-sh/bun/compare/main...claude/phase-a-port https://github.com/oven-sh/bun/compare/main...claude/phase-a...
• Tiberium 5mo ago
  I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better
  • chris_st 5mo ago
    And they're clearly marked as `unsafe`, so easy to find, which gives them a nice list of issues to address.
  • mi_lk 5mo ago
    > Bun has had an extremely high amount of crashes/memory bugs Any stats/source? Not that I think it's false > and the ugly parts look uglier (unsafe) which encourages refactoring. Looks like Bun owes that to itself to some extent, not solely because of the language
    • enricozb 5mo ago
      I believe the author is the creator of Bun.
      • brazukadev 5mo ago
        Is he working for Anthropic now?
        • danaw 5mo ago
          anthropic bought bun recently
          • brazukadev 5mo ago
            That's exactly my point. The fact they created Bun does not mean they will do what's better for Bun and the people using it.
• tmaly 5mo ago
  Just a cautionary case of porting to Rust using AI https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...
  • 8note 5mo ago
    i think theres a different lesson to be taken from those cases - the LLM will build to what you give a feedback loop for. if you give just the logical tests, it wont consider the speed at all. if you included tests that measure the speed and ask the llm to match the performance, itll do that too. its the same class of error as everything else with llms. it has no common sense context for things people consider important. if you dont enforce the boundaries, it will ignore them
    • alphabeta3r56 5mo ago
      Question is, are our optimization functions well specified enough? (No) How important is well specified opt function? No one knows. We will find out
  • dang 5mo ago
    Discussed here if anyone's interested: LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 https://news.ycombinator.com/item?id=47283337 - March 2026 (422 comments)
  • yrds96 5mo ago
    Also passing tests doesn't mean something works. Claude code C compiler passed 100% of gcc tests and couldn't even run a hello world...
    • GaggiX 5mo ago
      The C compiler written by Claude a few months was able to compile a hello world. The main problem I think that it was extremely slow.
    • 5mo ago
• legerdemain 5mo ago
  From 4 days ago: https://news.ycombinator.com/item?id=48019226 https://news.ycombinator.com/item?id=48019226 > I 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.
  • logicprog 5mo ago
    Looks like he did the maintainability performance and test suite checks and made his decision :)
    • jazzypants 5mo ago
      Honestly, I fully support the rewrite to Rust, but he should have just owned this from the start. I'm sure he knew in the back of his mind how dedicated he was to that branch as he had already spent the equivalent of thousands of dollars in tokens by that point.
      • skybrian 5mo ago
        Announcing the decision a week earlier wouldn't help anyone. Maybe he expected it to work (though he didn't say that), but there's no reason to make a final call before seeing that it did work.
        • jazzypants 5mo ago
          Fair enough. I didn't say anything about a "final call". It just feels like there is a middle ground between that and telling people they are overreacting.
      • fragmede 5mo ago
        Yeah but with no guarantee that it was going to work, why should he have?
• timetraveller26 5mo ago
  3 years from now: Linux ported to Rust in 6 days. And on the seventh day Claude ended His work which He had done, and He rested on the seventh day from all His work which He had done
  • kennykartman 5mo ago
    That's a fun point. I honestly don't think it will happen in 3 years, but I think it will surely doable in 10. More interestingly: will we need to care about the code at all, at that point?
• nine_k 5mo ago
  > 99.8% of bun’s pre-existing test suite passes on Linux x64 glibc in the rust rewrite OK, they've got a working prototype, congrats! Now it needs to be put into shape so that all the unsafe blocks are eliminated (maybe with a few tiny exceptions), and the code is turned into maintainable, readable, reasonably idiomatic Rust. I wonder how long is it going to take.
  • deleted 5mo ago
    [deleted]
  • amarant 5mo ago
    About 2 months, or 60 days, if we go by the old 90/10 rule. Not sure that rule is even applicable anymore, but I don't have a better heuristic to make guesses by either.
    • txdv 5mo ago
      maybe its tokens instead of time now? bun has access to an unlimited amount of it
  • mustache_kimono 5mo ago
    > Now it needs to be put into shape so that all the unsafe blocks are eliminated All the unsafe seems to be FFI? https://github.com/search?q=repo%3Aoven-sh%2Fbun+unsafe+language%3ARust&type=code https://github.com/search?q=repo%3Aoven-sh%2Fbun+unsafe+lang... > and the code is turned into maintainable, readable, reasonably idiomatic Rust. I wonder how long is it going to take. This isn't a c2rust rewrite?
    • ameliaquining 5mo ago
      That GitHub search only covers the main branch, not the not-yet-merged Rust rewrite; the only Rust code in there is tests for Rust FFI (so that people can write native extension modules for Bun in Rust if they want to). The rewrite's in https://github.com/oven-sh/bun/tree/claude/phase-a-port https://github.com/oven-sh/bun/tree/claude/phase-a-port. By running the following command on it, I count about 14,000 unsafe blocks: rg --stats -g '*.rs' 'unsafe \{|unsafe impl|#!?\[unsafe\('
• born-jre 5mo ago
  Being anthropic accuired project does he have access to mythos or it’s normal Claude we plebs have access to
  • bel8 5mo ago
    As an Anthropic acquihire, not only does he have access to every model and service but he probably has infinite tokens available. Bun powers Claude.
    • nine_k 5mo ago
      Indeed, knowing the amount of tokens spent would be very interesting.
    • rishabhaiover 5mo ago
      Also, isn't it a great ad for Anthropic itself? One wonders
  • tempest_ 5mo ago
    This is entirely possible with Claude as it existed even last year. The LLMs are quite good at re-writes and even better when provided an 'oracle' like a well rounded test suite or existing implementation to work against. Its part of the reason we keep seeing "I rewrote <library> in <language>" posts on hackernews and when you look at the repo its more like I prompted claude to rewrite this repo in rust or whatever.
• pdhborges 5mo ago
  Curious how the test suite was applied. Was it ported from Zig to Rust beforehand?
  • 190n 5mo ago
    Almost all of Bun's tests are written in JavaScript run in Bun itself.
• afavour 5mo ago
  Presumably the biggest loser in all this is Zig, I only know of the language because of Bun. But the timescale still gives me pause… just because AI lets us convert a codebase in 6 days doesn’t mean it’s wise. There are surely a lot of downstream implications! It’s always felt a little like Bun is making up a plan as it goes along (and maybe that’s unfair), this seems to underline the point.
  • nine_k 5mo ago
    Zig is a great low-level language. It's much better than C, while not being so much larger as e.g. Rust or C++. AFAICT Zig does well in embedded development, and should continue to do so. Note that Zig is not even 1.0 yet.
    • internet2000 5mo ago
      Yeah but now they got the fame of the language that fumbled the ball because of an overly onerous anti-AI stance.
      • Chris2048 5mo ago
        It's been repeated many times that the rejection of the Bun PR was unrelated to their AI-policy. It's also not clear they've "fumbled the ball" given how many projects are complaining about slop PRs.
        • stingraycharles 5mo ago
          I think it would help if Zig put out a statement on their actual AI policy, regardless of whether they’d be repeating something that should already be known. As often happens, the online discourse has, for some reason, decided that this was an anti-AI stance, while - as far as I understand - the problem was simply that the PR had problems, which lead to Bun forking Zig.
          • chrisco255 5mo ago
• pjmlp 5mo ago
  > why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. As expected, Modula-2 / Objective Pascal like safety was great during the last century, before automatic resource management, and improved type system became common in this century. Naturally also have to note, wasn't this supposed to be only an experiment, nothing serious?
• torben-friis 5mo ago
  >this is a 960,000 LOC rewrite, the code truly works, passing the test suite on Linux and soon other platforms I wonder how much of this is original size vs rust requiring verbosity vs the LLM being verbose in general. Not a criticism, I do believe language translation it's the one field that AI is mature enough to near one shot projects.
• deleted 5mo ago
  [deleted]
• mohsen1 5mo ago
  Very impressive that they could do this so quickly because I have been on a similar project (porting TypeScript to Rust) for 5 months. But I guess I don't have access to Mythos and unlimited tokens. I'm also close to 100% pass rate. 99.6% at the time of writing. https://tsz.dev https://tsz.dev Rust is perfect for writing all of code using LLM. It's strict type system makes is less likely to make very dumb mistakes that other languages might allow. Also want to note that writing the code using LLM doesn't remove the need to have a vision for the design and tradeoffs you make as you build a project. So Jarred and his team are the right kind of people to be able to leverage LLMs to write huge amounts of code.
  • kayson 5mo ago
    When Microsoft rewrote it in go, there was a comment from one of the leads that they chose it over rust because of the similarity in paradigms (garbage collection, etc), and that using rust would've been more difficult, requiring a lot of "hoop jumping". Now that you've done it... Thoughts?
    • mohsen1 5mo ago
      Yes indeed. More than 1 million lines of code (including tests) is jumping lots of hoops but with LLMs it's not as painful so you can just ask it to do the hard things. Example of a Claude Code session after 2 hours of "Crunching" that came out without results https://github.com/mohsen1/tsz/pull/4868 https://github.com/mohsen1/tsz/pull/4868 (Edit I force pushed to PR to solve the problem, you can see the initial refuse message in the initial version of PR description) Funny thing is, the last percent of the test have been so hard to work on that Opus 4.7 routinely bails and says "it's too involved or complicated" so I had to add prompts specifically asking it not to bail.
      • odie5533 5mo ago
        Do you have any write ups on your workflow with Claude and github dev?
      • baq 5mo ago
• parliament32 5mo ago
  [flagged]
• pbohun 5mo ago
  How many tokens did this port consume?
  • allthetime 5mo ago
    Bun is owned by anthropic and so has access to Mythos & unlimited tokens. The answer is... more than any of us could likely afford.
• onlyrealcuzzo 5mo ago
  And here I am trying to get an LLM to add types to a 100k line Ruby repository for 2 days, and it's not going so hot...
  • adsharma 5mo ago
    A SMT solver may work better.
    • onlyrealcuzzo 5mo ago
      Will that work if my codebase is filled with nils it shouldn't be filled with, and HashMaps instead of structs with a loosely defined schema, and tuples masquerading as arrays?
      • hope2 5mo ago
        [dead]
  • phamilton 5mo ago
    I have some experience in this. Reach out (email in my bio) I would love to chat.
• dlenski 5mo ago
  Deleted
  • logicprog 5mo ago
    @simonw explains how hilariously misguided that paper is in one of the top comments, and how it doesn't apply remotely to a real agent harness. Plus it's not even clearly relevant here, because the model isn't trying to regurgitate the original document, but generate a new one, and there are guardrails to put it back on track in the form or a compiler and tests. Also, the test suite is very thorough, and pre-existing, and the vast majority passes already. This is skepticism for the sake of it.
  • raincole 5mo ago
    Perhaps you can elaborate on how your comment is relevant to the Bun's experiment here.
• redsocksfan45 5mo ago
  [dead]
• lerp-io 5mo ago
  [flagged]
• arto 5mo ago
  The fastest large-scale rewrite in the history of software engineering, likely
• Robdel12 5mo ago
  Bun is going this route because their proposed fix wasn’t great. https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilation-times/15183/18 https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio... Cannot imagine this agent rewrite had anyone review any the code (you can’t at that speed). I’m positive this will go extremely well :p
  • davidatbu 5mo ago
    Fwiw, that's not the stated motivation for the rewrite experiment. In fact, the Rust rewrite is slower to compile than the zig code when compiled with their internal fork of zig (tho it is faster when OG zig is used). I don't want to infringe upon your right to speculate. I just want to point out that your statement is at best a speculation.
• perching_aix 5mo ago
  > and crashes and stability issues inb4 .unwrap() / slice / etc hell + livelocks & deadlocks + resource leaks & toctou bugs + larger exposure to supply chain attacks Still, ~1M LOC ported in a work week (400 LOC/min, wtf?) and almost all of it working is pretty wild. I hope the guy managed to maintain normal function, cause I found that getting into the flow but with AI is even more self-consuming and intoxicating than without it, which was already potentially rather rough.
  • aabhay 5mo ago
    At 100 agents in parallel that’s 4loc/min, and 100 agents is a lower bound on what they had access to.
    • perching_aix 5mo ago
      It's not so much the agents' througput I'd be worried about, more meant to imply that at such speed, large parts of this are going to be pretty much just guaranteed unsupervised / unchecked completely. Like literal "LGTM + god bless + fuck it we ball" tier.
• arjie 5mo ago
  This is remarkable. Man, there are all those ancient things that "we've lost the source code for". One time, in a past job 10 years ago we were reimplementing something that was lost to the sands of time, using an out of date spec it had used. It was such a tedious job with verification but we got there. Amazing how easy that would be today.
  • thfuran 5mo ago
    I don't think this kind of thing works nearly so well without a comprehensive test suite or the ability to easily use the reference version as a test harness. The typical enterprise relic for which no specification or source remains almost surely lacks the former and probably isn't very amenable to the latter.
  • tkiolp4 5mo ago
    Are you sure you will be able to spend time playing around that kind of stuff when anthropic/openai/google/etc make you jobless? (well, perhaps not YOU precisely, but 90% of devs, so there’s a high chance). We always think it’s not gonna hit us… we may be wrong
• ekjhgkejhgk 5mo ago
  Explain it for dummies. Isn't Zig a programming language? Why are they re-writting a programming language in another programming language?
  • conradludgate 5mo ago
    They're not rewriting zig. They're rewriting bun, which is currently written in zig
• lujeni_ 5mo ago
  No doubt on my side porting was "easy". What I’d find interesting is the ability to maintain and properly care for the code over time for the next iterations. Do we eventually end up with a codebase that nobody truly understands in depth anymore, where everything is generated and modified through GenAI? Thanks for the sharing
  • oytis 5mo ago
    Yeah, that's my issue with llm code. If we imagine a future without human programmers - sure, go ahead, we are not there yet, but maybe it's possible. But if you want it to coexist with humans, then it doesn't seem to work well. It gets in the way of human learning and human communication. Making professionals and teams weaker essentially
• languid-photic 5mo ago
  would be fun to do zig -> rust -> zig and to measure the delta (in a VAE-ish way, kl div on the embeddings?)
  • languid-photic 5mo ago
    also feels like a good posttraining task
• declan_roberts 5mo ago
  The Pareto principle is in play here. It might take years to get that last percentage point.
• amai 5mo ago
  Bunner
• fastball 5mo ago
  Obviously bun having been acquired by Anthropic changes the arithmetic a bit, but I'd love to see the token cost/consumption of this initiative.
• jedberg 5mo ago
  Obviously there is a huge trend of "rewrite X in Rust". I understand why, Rust is a huge improvement in safety and speed. My question is, to people even older than me (and I'm certainly not young), does anyone remember this much enthusiasm about people rewriting C code into (C++/Java/Whatever was new and hot)? Because I don't, but maybe I missed it.
  • Onavo 5mo ago
    There were no good options previously. It was either C or C++. Most of the other languages were either fringe or had a GC, or had a pseudo runtime GC (Swift). The culture of Java and C# and Go didn't really support the type of low level optimizations needed, even though you could technically do system programming if you restrict yourself to a specific subset of language and cut yourself off from most of the standard library and ecosystem. Nim was unstable. OCaml had the same issues as Go and Java and C#. You simply did not have any options until Rust came along. Oberon was an academic trinket. The less said about the various lisps and forths the better. OS and embedded programming require bare metal support and data structures that can run standalone in the absence of an OS and standard library, and the ecosystem must exist to support such a style of programming. Currently Rust has over 10000 crates that would theoretically work just fine in an kernel environment. https://crates.io/categories/no-std https://crates.io/categories/no-std
  • libria 5mo ago
    I recall C++ OOP being the new hotness when I started out and C was always contrasted as the old & busted example. Kind of the "Everything-as-an-object will simplify everything" phase. Windows MFC was the new way, then STL. Java WORA write once, run anywhere was definitely a thing when it came out. Java Applets came out of the woodwork and were the WASM of their day. Even Cisco ran Java for their router UI for a while, which was painful. More recently, HN went through a period about 10 years ago where every other article ended in " ... written in Go". The mantra may not have rhymed with "rewrite X in Y" but the spirit was there.
    • russum 5mo ago
      > every other article ended in " ... written in Go" What happened to that: is Go no longer considered great / popular?
• boring-human 5mo ago
  I harbor some hope that the (sad) fall of human SWEs will at least be accompanied by language defragmentation. We don't need 38 systems languages once human taste is mostly out of the picture.
  • _heimdall 5mo ago
    Since the LLM craze started I have always assumed it would end up in a place where programming languages are dead and LLMs generate something more low level. Programming languages were always designed as an abstraction to allow humans to more easily instruct a computer than by writing binary or assembly. If humans write natural language and don't check the generated code, there's no reason to take the hit of generating C, JS, etc that still has to be compiled and/or interpreted.
    • rafaelmn 5mo ago
      If anything LLMs should use something higher level because it compresses the context and makes programming closer to natural language they are trained on. Forcing LLMs to do a shitty job of what a compiler can do deterministically is not a good approach IMO.
      • _heimdall 5mo ago
        Low level was the wrong term for me to pick there. I was meaning more along the lines of "purpose built". I.e. I could see a language, potentially still an abstraction requiring a compiler, that isn't meant to be particularly meaningful or inspectable by humans. For LLMs your right, conciseness would be important and that would likely mean it would be compiled.
        • not_paid_by_yt 5mo ago
          you're both under and over estimating this technology I think, we are further away from SWE becoming a niche job than you think, but also LLMs really are less impacted by programming language than you think, this is a very pre-2010s approach to NLP, it really matters quite little to a language model what language the code is in, you could have it write it in Python using exclusively Chinese logographs for names, and exclusively French transliterated into Mayan script for comments and it might barely perform worse than if you asked it to do something normal, but that also goes in the other direction, trying to design a language that's "friendly" to LLMs will likely not do much good either. The reality is there's a massive amount of data on existing languages and they are good enough for LLM usage. I think if changes will happen in this direction it will be around formal verification, it's more difficult to trust LLM generated code if you aren't completely brainroted on press releases, and traditionally formal verification was seen as more effort than it's worth, but a tool that's great that generating insane amounts of text is quite well suited to formally verifying code, and assuming you can figure out how to make the specification readable to people, you just don't (in theory) need to ever look at the code or the proof, even if it might be helpful to anyways in practice. I'm quite excited the future of software might be fully unhackable software being the standard, with hacking becoming something that's talked about as a brief criminal fad in the beginning of the 21st century, like how you might hear about coin clipping from before fiat currency.
• AtNightWeCode 5mo ago
  Kinda crazy to use AI to switch from zig to rust in a tool that runs js. Bin bun and use a real lang to begin with. No reason to have that extra layer anymore.
  • dare944 5mo ago
    Lol, I had a similar thought as well, but more along the lines of "We're coming for you next, JavaScript!" But the effort is certainly an exquisite rearrangement of the deck chairs, no?
  • bel8 5mo ago
    Bun runs TypeScript directly without external tooling. bun script.ts just works. Otherwise I bet it wouldn't even be a blip in our radar.
• sergiotapia 5mo ago
  jared's post is singlehandedly shitting on Zig's reputation. not good juju for him to post like that. "I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues" bun was zig's poster child. if it moves away, it becomes yet another random language like nim or crystal.
  • iExploder 5mo ago
    I'd feel better to have that kind of person out of my community. First of all, did he not pick the language for Bun himself? Then introduced bunch of memory bugs, sound like skill issue cascade. I remember some years ago in podcast touting how amazing Zig is to allow them being so performant which was the claim to fame for Bun, now to turn around and shit on the thing. Interesting persona.
• suck-my-spez 5mo ago
  Serious question… Who’s going to want to run a vibe coded runtime in production? I don’t see how this is a good look for Bun?
  • Narishma 5mo ago
    I think you overestimate the number of people who care how the software (or any product really) they use is made.
  • zaptheimpaler 5mo ago
    I just see a ton of reflexive AI hate here. I don't care if it was vibe coded, if it passes the entire test suite and was vibe coded by the original authors, I trust it as much as the original Bun. These are Jarred's words about it: > it’s basically the same codebase except now we can have the compiler enforce the lifetimes of types and we get destructors when we want them. and the ugly parts look uglier (unsafe) which encourages refactoring. > why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. This makes me trust it more, not less.
  • kennykartman 5mo ago
    One should care about tests more than how code was coded. If I had a codebase with lots of tests and asked someone else to rewrite it to another language passing the same test suite, I honestly wouldn't expect a great quality job. I say this because it happened 3 times in the company I work for: we conducted experiments by tasking different companies to rewrite the same code in another language. All of them passed (most) of the tests, but code quality was low. If the job is a black box, rely on the I/O to determine quality, not the inner workings.
    • hellcow 5mo ago
      I care that runtime developers know and understand their codebase deeply. 1M LOC written by 1 dev in a short time does not inspire confidence in such an important dependency. There's no way this code is understood fully by the original author, let alone anyone else. I wouldn't accept this from an intern, let alone in code that's fundamental to my business.
• dangoodmanUT 5mo ago
  If this goes through, it feels like it will stoke rust on zig violence
  • kennykartman 5mo ago
    Sadly, yes. I feel too much "violence" on both parts. Honestly, Zig community seems the most bitter for whatever reason, while on the Rust side it seems to me that are simply overstating how great the language is and are pushy in trying to convince the other of their ideas. If this goes through, we can all take SWE lessons from it, but I think the communities will suffer.
  • leecommamichael 5mo ago
    I just wish the camps would stop being as tribalistic. I see a broad spectrum of fights between any "better C" language and Rust enthusiasts. There is room for both of these things. Just use what works for you. Rust is a bit more like Ada in spirit, it introduces a lot of friction compared to "C like" things which gladly accept you blowing your leg off. Each tool has unique benefits, and is uniquely suited to different problems. If I'm building a simple GUI app, I'm not sure the friction from Rust is all that worthwhile. If I'm sending someone to space, I think I'd rather have the safeties of a Rust or an Ada, or MISRA C.
  • lukaslalinsky 5mo ago
    I really don't think so. Bun was using their own language, that forked from Zig 0.14. It's not like the communities interacted much. All of Bun's code was their own internal code, it was not part of the Zig ecosystem. I don't see how this could have any impact in the Zig community at all.
• jdw64 5mo ago
  [dead]
• roschdal 5mo ago
  Meh. I prefer Java, all hours of the day, every day of the week.
• ec109685 5mo ago
  There is no way a port this massive will have human code reviews. If this succeeds, there is no stopping AI given it will have crossed the rubicon of human bottlenecks.
• matrix12 5mo ago
  will this mean opencode is finally portable?
  • jauntywundrkind 5mo ago
    There is some really cool work to port opencode's underlying opentui to Node.js, including some new FFI work in node itself that got merged (called... drum roll please... node:Ffi! Really cool stuff. https://github.com/anomalyco/opentui/pull/939 https://github.com/anomalyco/opentui/pull/939 https://github.com/nodejs/node/pull/62762 https://github.com/nodejs/node/pull/62762 Also worth noting that opentui is... Zig! Very unclear what it's going to take to get this reviewed and shipped, but some very high potential. I've seen some other changes going by in opencode for node.js compatibility; I'm not sure what besides the tui has Ffi needs that might be gating; maybe nothing!
• CrzyLngPwd 5mo ago
  I'm looking forward to the race to the bottom in the tokens-for-work-done race.
• grigio 5mo ago
  STOP Analyzing.. Now rewrite the Linux kernel in rust. DO NOT MAKE MISTAKES, then post it on Hacker News. ---
• mikebelanger 5mo ago
  Interesting that ports can be written so quickly with AI. But that aside, I have to ask...why? You want a super performant bundler/runtime/package manager written in rust with TS support, Deno has this already.
• the__alchemist 5mo ago
  Bun alert!
• taosx 5mo ago
  That's amazing, over time I got a few memory related crashes w/ bun but have deep respect for the performance work put in. Hopefully Rust's compiler will help even more. Off: I'm wondering if now when more JS finds place on our machines and bundle size is 2nd place for most, would a revival of prepack or projects in the same vein would be worth it, especially with agents.
• Validark 5mo ago
  I'm a full time Zig developer, and I see this as an absolute win. I know Jarred has said in the past he feels Zig makes him more productive, but I also think it's fair to say Bun was programmed in a way that's quite cavalier towards buffer overruns. I think Jarred and the Oven team will have significantly better luck with Rust. Some commenters have remarked they only heard of Zig because of Bun, therefore this is bad for Zig. Not so. In my opinion, there has always been a mismatch. I say with no ill will that a divorce is likely better for both parties. I genuinely believe Bun will be better software once fully converted to Rust.
  • hitekker 5mo ago
    Not sure why you're getting downvoted; I think you're close to right. They were successful with one technology and had a great exit. They may also be successful with another technology post-acquisition. Lets see the fruit of their decision.
  • anttiharju 5mo ago
    I remember looking into the nodejs alternatives some years ago, one way to compare them is to look at the open issues. bun had so many hits for 'segfault' and deno has basically none. Even now: bun (zig) [1] 119 open / 885 closed deno (rust) [2] 0 open / 1 closed I don't think this has that much to do with Zig's anti-AI stance. More about using the right tool for the job. [1] https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3... [2] https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20segfaut https://github.com/denoland/deno/issues?q=is%3Aissue%20state...
    • chrisco255 5mo ago
      You misspelled segfault as segfaut on your Deno search: https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/denoland/deno/issues?q=is%3Aissue%20state... There 10 open and 40 closed on Deno.
      • 5mo ago
• hacker_88 5mo ago
  Merge with Deno
• deleted 5mo ago
  [deleted]
• jwpapi 5mo ago
  Completely unbased, but I don’t want to have to do anything with bun anymore. It’s just a gut feeling, but I don’t trust them and support them. They fork Zig to utilize LLM rewrites and build something the Zig team clearly disregarded (non-deterministic compiling) And now like a whiny baby they LLM rewrite to Rust. There is a very real chance that Zig design philosophy got them to the point where they are now by enforcing to make the tough but precise decisions and the Rust rewrite is the start of the downfall. It’s purely politics-based not technical, but it seems like bun is full on pampered by Claude. So much that I wouldn’t wonder that the next marketing piece of Anthropic is. Claude Mythos rewrote leading 950k LOC JS Runtime to Rust.
  • deleted 5mo ago
    [deleted]
  • tln 5mo ago
    > And now like a winey baby they LLM rewrite to Rust. I didn't see any whining from Jarred, this seems like misplaced sentiment > It’s purely politics-based The linked twitter thread gives clear technical justifications
    • cute_boi 5mo ago
      It looks more political than technical. Also, criticizing the Zig team for not making any AI contributions before this gives a hint.
      • deleted 5mo ago
        [deleted]
    • jwpapi 5mo ago
      > I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues There are legit reasons to rewrite a program in a better fitting language, but as a runtime to be "tired of worrying about & spending lots of time fixing memory leaks and crashes and stability" is really borderline to me. Also there are way more things to it than just compile time and tests: you reset mental model and will lose contributers. There is philosophy, developer skill and more attached to a language. In this case both compile via LLVM the same and there is no performance benefit given the code is written exactly the same, so it’s developer preference, where the current head seemed to prioritize his own DX over everyone else’s. But again this is mainly my gut feeling. I’m not the first dev that doesn’t like the way bun changes : https://news.ycombinator.com/item?id=48011184 https://news.ycombinator.com/item?id=48011184
• timcobb 5mo ago
  The Ubutnu coreutils thing last week really soured me on 99.8% test compatibility Rust rewrites :|. I clicked through to the tweet linked here and it was kind of like shudder I feel quite opposite now when I see this kind of thing. I'm like *looking for exit*
• voidhorse 5mo ago
  So let me get this straight: Developers use LLMs to migrate a million line codebase to a language that they have much less experience with in such a short amount of time that they likely do not have a good mental model of the migrates code. At least the tests pass. Only one person drove the migration, so the number of people that understand the new code is ~0.5 under the assumption there's no way the sole dev could build a mental model of fresh 1m code in 6 days. This is code for a language runtime. It's great that the tests pass but it's really hard for me to interpret this as anything other than horrible mismanagement of a promising project. When you sit this low in the stack this is grossly irresponsible and I have no idea why anyone would use Bun after this. You'd be literally adopting a runtime the devs presumably don't understand, keep in mind they now somehow need to evolve and maintain this in the future. Hopefully this remains an experiment, or Bun has some plan for re-upping dev knowledge of the codebase. Sorry but a component with massive blast radius like a runtime isn't really a good candidate for vibe coding, no matter how good the AI is. I'd like the maintainers to actually understand their runtime, thanks.
  • jwpapi 5mo ago
    Thank you put my gut feeling that I had in my top comment here in words. I didn’t have the full explanation ready, why this threw me off.
  • slopinthebag 5mo ago
    They won't, they will continue to vibe code it until it collapses under them and the project fades into obscurity. Which it will regardless since it was acquired by Anthropic. Node beat Deno and Bun. Pretty impressive.
• Twey 5mo ago
  Were there perhaps [licensing issues](https://www.phoronix.com/news/Chardet-LLM-Rewrite-Relicense https://www.phoronix.com/news/Chardet-LLM-Rewrite-Relicense) with the original?
• sourcegrift 5mo ago
  Do scala.js next
• Jimmy0252 5mo ago
  [dead]
• mjtk 5mo ago
  The flagship product is both the cash cow (subsidizes rewrite) AND the labor (amortizes? rewrite).
• up2isomorphism 5mo ago
  best way to kill an open source project in 2025 - use AI to port it to Rust.
• Amber-chen 5mo ago
  This is a good reminder that tooling choices compound over time. The short-term speedup matters less than whether the next maintainer can still reason about the system.
• FjordWarden 5mo ago
  I love Bun & Zig and this feels a bit like my parent are getting a divorce. I thought it was a bit strange that Bun did not sponsor the Zig foundation while others much smaller companies have.
  • Validark 5mo ago
    Are you kidding? IIRC Oven gave $5k/month to Zig for years. And btw that was before they got acquired for billions, when they had no income at all.
    • FjordWarden 5mo ago
      Alright my bad I did not find any info about this, but still they are no longer mentioned as a sponsor.
    • hitekker 5mo ago
      Yeah, that tracks according to the numbers. https://ziglang.org/news/300k-from-mitchellh/ https://ziglang.org/news/300k-from-mitchellh/ https://ziglang.org/news/2024-financials/#income https://ziglang.org/news/2024-financials/#income https://ziglang.org/news/2025-financials/#income https://ziglang.org/news/2025-financials/#income I had a bit of trouble finding it myself but Claude proved a better Googler than I
  • deleted 5mo ago
    [deleted]
• matt3210 5mo ago
  Guys calm down, this is just marketing from anthropic the same as the browser and the c compiler.
• jFriedensreich 5mo ago
  I still don't understand how people consider bun as a viable runtime when its owned by evil corp trying to use it for capture of the tooling layer and its the most insecure runtime on top of that. Meanwhile deno is performant and has dramatically improved node compatibility while exposing a proper permission broker api.
• marsven_422 5mo ago
  [dead]
• Ati985 5mo ago
  [dead]
• AppAttestationz 5mo ago
  I suspect that the test suite isn't that great tho. Bun has so many different behaviors compared to other JS engines, sometimes just plain wrong or contradicting the spec. Test suite didnt catch those.. Not sure how much I trust the rewrite :)
  • anematode 5mo ago
    Notably, Bun is not a JS engine. JavaScriptCore is the JS engine. Bun is just a complicated wrapper around it.
    • AppAttestationz 5mo ago
      With the amount of changes they've made to WebKit, I honestly don't think we can claim it's just JSC.. https://github.com/oven-sh/WebKit/commits/main/ https://github.com/oven-sh/WebKit/commits/main/
• kombine 5mo ago
  They could also do a rewrite of CC itself to Rust.
• chenzhekl 5mo ago
  [dead]
• BLACKCRAB 5mo ago
  [dead]
• perlgeek 5mo ago
  Has anybody thought through the legal aspects of this, regarding code ownership? As far as I understand the situation in the US (sorry, no idea where he is located), output from LLMs, once published, is essentially in the Public Domain, since there isn't any human who owns it. However, in some sense, this is also a machine-assisted translation from one computer language into another, so one could argue that the ownership of the original code base still applies to the new one. Which one is it? Is there any way to find out before a similar case goes to court?
  • muglug 5mo ago
    > output from LLMs, once published, is essentially in the Public Domain, since there isn't any human who owns it That’s not what the court case in question was about: https://www.morganlewis.com/pubs/2026/03/us-supreme-court-declines-to-consider-whether-ai-alone-can-create-copyrighted-works https://www.morganlewis.com/pubs/2026/03/us-supreme-court-de... If I ask an LLM to come up with an entirely new story on its own, the output is not copyrightable. But if I feed an LLM a Tom Clancy novel and ask it to regurgitate that same novel, I cannot legally then put the output on a website for anyone to download.
  • Gigachad 5mo ago
    AI rewrite one of the Microsoft source code leaks to Rust and publish it as open source on GitHub. We will soon find out what the answer is.
• itdoesntmatter4 5mo ago
  [dead]
  • hawkice 5mo ago
    Obviously LLMs would identify as binary. (But also, low effort meanness is bad, HN strives for better in both dimensions)
• ALLTaken 5mo ago
  Now in Zig, Julia, Nim, Crystal. I just love programming languages. But in all honesty, I don't understand the extremism in Rust engineers that reject any other language.
  • ChrisTrenkamp 5mo ago
    I think it was Rich Hickey who said "Programmers understand the benefits of everything, and the costs of nothing." I'm also reminded of video game forums where everyone argued whether the Xbox or Playstation is better, not because they're genuinely interested in the pros and cons of each system, but because they only have an allowance to buy one of them, so they're trying to gaslight everyone and themselves into believing the one they picked is better. In the case of programming languages, there's only so much time in the day, so the people who post on this site go all-in on the programming language they picked, and will rationalize any reason they can think of to believe the language they picked is better.
  • smj-edison 5mo ago
    Steelmanning a rust programmer's argument: memory issues have a very large blast radius, as the bugs tend to show up in completely unrelated. Because of this, dependencies on languages not written in Rust can easily corrupt areas that are unrelated. I feel like one of Rust's defining philosophies is modularity, in the sense that each module should be self-contained, and have clear boundaries. This can come up as an assumption behind their arguments imo.
• hsaliak 5mo ago
  Its going to be interesting to see how this holds up in production after a release or two.
• ptnpzwqd 5mo ago
  Responses seem to be very "either or" as usual on such topics. I think it should be possible to appreciate how impressive this is on one hand, while also discussing the limitations of the approach. Everyone can probably agree that getting this far without LLMs would have taken substantially longer and required a huge amount of work. But what is then the end result? Personally, for me it would still be hard pass on using a 1M LoC LLM-migrated language runtime - I have seen CC do enough crazy things to still be wary of any code without a human in the loop. It simply plays too fundamental a role in the tech stack. Others might feel differently, and time will tell how things play out. Even if this does play out as optimistically as one can imagine, would it then mean I can go and migrate some of my enterprise codebases the same way? I doubt it. Bun has the nice feature that it has an extensive set of black box / E2E tests that don't themselves need migrating. Most projects in the wild seem to be much more reliant on unit and integration tests that are part of the codebase itself, and would therefore also need to be migrated and be subject to mistakes in the migration process. It also seems fairly rare that test suites are good enough to guarantee that the program will work as expected in all cases. I am yet to come across a larger enterprise codebase where the tests were good enough to make human review and even manual testing fully redundant. To be honest I doubt that is the case for Bun either, but I don't know enough about bun to conclude that.
• aero-glide2 5mo ago
  When is someone going to do linux rust rewrite
  • wolttam 5mo ago
    It’s relatively easy to get a basic Unix-liked kernel together. Hardware compatibility (and associated testing) is where it gets hard.
• gbgarbeb 5mo ago
  Xunroll's "view on X" truncates the first character of the username.
• m463 5mo ago
  [flagged]
• bobkb 5mo ago
  This is a manual rewrite or auto generation ?
• ptdorf 5mo ago
  So... this was a lie