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

cargo check reported over 16,000 compiler errors when I wrote that message. It could not print a version number or run JavaScript. I didn’t expect it to work this quickly and I also didn’t expect the performance to be as competitive. There’ll be a blog post with more details.

"No one has the intention of building a wall" - Walter Ulbricht, chairman of the central committee, a couple of months before the Berlin Wall was built.

The AI companies and their associates are beginning to surpass that level of denials and lies.

Looks like he did the maintainability performance and test suite checks and made his decision :)

Yeah, that means it's an extremely successful experiment so far.

Also a few days before that:

> I expect OSS to go the opposite direction: no human contribution allowed. Slop will be a nostalgic relic of 2025 & 2026.

We should have seen this coming after they got acquired by Anthropic, but it's still disappointing. I'm not against large language models as a technology, just thoroughly disgusted how these "AI" companies rose to power, eating the software industry and the rest of society. It's creating a very unhealthy dependency.

Think a few steps ahead and start preparing a slop-free software stack and community. That includes Zig and its ecosystem. Even if we (and future generations) don't manage to live entirely without slop, it's more important than ever to ensure a sustainable computing culture, free as in freedom.

He works at claude, he has unlimited tokens. He can do anything, he is using mythos.

I think such re-implementations will be a huge asset to the process of software developments in the future.

[flagged]

What's your point

> 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.

I question this. Yes, strong enforcement of invariants at compile time helps the LLM generate functional code since it gets rapid feedback and retraces as opposed to generating buggy code that fails at runtime in edge cases.

On the other hand, Rust is a complex language prone to refactoring avalanches, where a small change in a component forces refactoring distant code. If the initial architecture is bad or lacking, growing the code base incrementally as LLMs typically do will tend towards spaghettification. So I fear a program that compiles and even runs ok, but no longer human readable or maintainable.

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?

Same but for multi-threaded Postgres[0]. 96% pg regression tests pass after 1 month and 823K LOC. 8 Codex accounts at $200/mo is what i could use up with no Mythos

I've also seen the benefits of Rust for this too. And making the bet that my pg experience will help me make good design choices around many of the things people have been having trouble with in pg for a long time[1]. Excited to see AI make it more possible to improve complex pieces of software than has historically been practical.

[0] https://github.com/malisper/pgrust [1] https://malisper.me/the-four-horsemen-behind-thousands-of-po...

Rust is amazing, but the way I want to build Rust software breaks down on large projects with LLMs. Maintaining clean boundaries or even just establishing them stops being a flow state and turns into painful reviews that push me into procrastination mode.

I’ve struggled to get Opus to not write the weirdest possible Rust, ignoring all idioms and so on. Any tips?

>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.

100%. I've been telling everyone who will listen this for 2 years. LLMs are infinitely more productive with swift code like

let engineCycleCount: Int = 5

vs

let eC = 5

They still make mistakes, but forcing _explicit_ typing in a strongly typed language makes them make far fewer mistakes + the compiler is catching >90% of what you try to catch with a billion rspecs in trash languages like ruby.

Wow, amazing work.

Pretty impressive that it is faster than the Go version already.

Zig is much more type aligned to bun than typescript. And there’s a common interface of C ffi so you could imagine porting it modularly and keeping the test suite in zig

>Rust is perfect for writing all of code using LLM.

Rust is a terrible language for using LLMs to write code if Rust's low latency isn't needed, because of its extreme compile times. LLMs code faster than humans so a far bigger fraction of the time is spent waiting for the compiler, and a reasonably sized project will take literally 10x longer to compile in Rust than in e.g. Zig or Go.

shouldn't typed code that uses functional style be kinda the perfect end game for llms? You can parallelize generation at any granularity, easily ring fence changes, reproduce everything, types give clues to the llm.

Interesting, but why not then use an even stricter language? Say Idris, ATS, Lean or F* ?

[flagged]

> 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

Last time i checked their issue tracker (in 2025), the main source of problem was the engine, not their Zig code. A lot of core dump was happening inside and around JSC.

> Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.

And they're clearly marked as `unsafe`, so easy to find, which gives them a nice list of issues to address.

Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?

Can you or someone shed some light on how much compute it took to do this?

[flagged]

Translating a project that includes a good test suite from one language to another is known to be a great case where LLMs work well.

When you’re starting with a complete codebase to use as an example and a test suite to check everything it’s much easier to iterate toward the desired goal. The LLM can already see what the goals are and how they’ve been implemented once already, which is a much easier problem than starting from a spec.

Unclear. Very good products tend to be about doing one or a few things very well; not about doing tons of stuff. So far, all I see is “Man, Im a 10x engineer now!”, shipping more code but without clear direction and taste. At this point, most of LLM-based work is just noise.

You could have said the same thing about steam power or electricity. And it’s not just an analogy: The magic of these things is in being universal information engines. You spend capital to build them, using well-understood, scalable techniques, plug them into electricity, and out comes value.

My point is, there’s no chance of a “haves and have nots” emerging, any more than electricity turned out that way in the modern world.

It's a new era of capital, literally, in software development. Ownership of the means of production is now concentrated.

Nah. These agents are getting easier and easier to run local. Have you tried Qwen 3.6 27b? It’s insane what it can do compared to its size. Like 100% vibe small projects if you manage context properly.

These models are a race to the bottom just like compute.

I can't help but wonder what this cost in USD assuming you paid standard rates from Anthropic. Can someone even ballpark the price?

There are not many companies that live off taking full test suite made over decades and just generating code off it.

With less employees....

Who's the whiny baby? The developer writing some code in their own repo, or the guy complaining about it on Hacker News?

I'm team Zig in most cases but I genuinely think they are better off with Rust. They have had a lot of buffer overruns and segfaults as a result of undisciplined Zig code. I think Rust actually is a better technical choice for them.

> 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

I agree. From the get-go, Bun was apparent in its design philosophy: we do everything you'd ever want; runtime, bundler, test suite, package manager, all in a new breaking patch each week. With each and every one blowing the established competition out, better, faster and stronger. But it was glaringly obvious that they'd do anything but Keep It Simple Stupid. It was obvious that the only production environment it would see the light of the day in the near future would be YC startups burning one after another at the speed of an accelerant. Now, they're past the point of no return.

> It’s purely politics-based not technical

Jarred mentioned having to work on fixing memory leaks as the main motivation to try this.

https://xcancel.com/jarredsumner/status/2053058171338682875#...

I was never fully comfortable with Zig given it's much less mature than Rust. Maybe this will be for the better.

I don't have the personal investment that you appear to have with Bun, but why does this matter? Do you scrutinize the rest of your dependencies this way?

Much of working in the JS / NPM ecosystem is already pure faith on un-vetted dependencies, and this appears no different pre or post LLM rewrite. If it satisfies the intended goal and API contract it originally did, is there any difference? Were you carefully reading the original source code before?

I consider zig the "whiny baby" approach to be honest.

Bun is effectively dead.

Anthropic bought it in a somewhat dumb attempt to solve their "performance" issues (not realizing their horrible code was the issue in the first place).

It probably helped them, simply because they brought in some actually competent developers.

But doing so, Bun went from being a public project to more of an internal tool for Anthropic, spoiled for now with AI money and losing quite a bit of focus.

Let's hope that when the bubble pops, some of the Bun effort could at least be salvaged. I don't see Anthropic maintaining it long term, they are simply not in the business of selling support for a runtime nor have the (Google) scale justifying maintaining one on the side.

Yep, the Anthropic acquisition, this petulant Rust rewrite, and bun's increasingly buggy releases (slop) have caused me to migrate my projects (personal and work) to nodejs+pnpm.

The risks of using bun are no longer just those concerns around a newer tech and "drop-in" replacement for nodejs. Now you have to marry Anthropic, Rust, and a founder with conflicting priorities.

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.

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.

It's still an impressive achievement that would have taken even the most competent engineers an exponentially longer time to accomplish.

I just hope it's noted when this is eventually marketed how much human effort went into designing and curating the test suite that even enabled this speed in the first place.

A test suite sort of functions exactly like the ideal scenario for current gen llms. A comprehensive enough test suite essentially forms the spec for agents to implement however they see fit - in this case rust.

You could probably throw away the entire actual source code in certain cases and reimplement the whole thing from scratch just giving an agent access to the tests when it's as well crafted as a project like bun.

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.

If this is a "beyond standard" test suite, (so much so that it _uniquely_ makes this work possible compared to other projects,) then how is Bun also uniquely unstable compared to other Zig programs (and so deserving of rewrite?) If the blame lies partially with the test suite, what does this imply (if anything) about the Rust port?

> Is every company that sells software as their core business model going to go out of business?

Probably not, for a number of reasons:

* Some software suites are (probably still for a few years) too big to regenerate them through a coding LLM

* There's quite a lot of proprietary knowledge not just in the code itself, but in the requirements, industry knowledge etc. For example if you want to write a hospital management system, you need to know a lot about how hospital works, how they are billing their services in different legislatures, data protection rules etc.

* For some pieces of software (like computer-aided engineering), validation of the software is just as important as the software itself.

* Liability: suppose you build bridges, and you're on the hook if it fails too early. Do you really want to vibe-code your own software that validates the bridge's design? Will any insurance company cover that? Probably not in the near future...

* Currently, security and safety of LLM-generated code is still a pretty big concern. I guess this will get better as the LLM-Coding industry matures.

> 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.

Let's take a SW business like a ticketing system.

Do you think 100 enterprises with 1 bln of tokens are going to make a better product than specialized vendor with 100bln of tokens?

For sure SW vendors and SAAS like "logo creator" are already dead, but unless the next generation of LLMs aren't going to have an embedded ticketing system the ticketing system vendor will be fine(maybe less headcount, but not sure).

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.

It’s pure marketing. Don’t be naive

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%3...

[2] https://github.com/denoland/deno/issues?q=is%3Aissue%20state...

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.

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...

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

Discussed here if anyone's interested:

LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - March 2026 (422 comments)

I’m Korean, and I’ve used GitHub Copilot, Claude Code, and Codex. At first, I prompted them in English, but over time I came to the conclusion that using Korean works better for me. It may consume more tokens, but reducing the time spent understanding and correcting the plan is more valuable. That said, when the context gets close to its limit, the responses sometimes include Korean words that do not actually exist.

As an aside, I don’t think the benefits LLMs bring to non-English users are widely understood. I studied linguistics and Russian, and I’m capable of professional interpretation in English and Russian. Even so, I can read technical documents, understand them, and communicate about them much faster and with far less effort in my native language, Korean. These days, I read most English documentation and HN posts through Chrome’s automatic translation. Sometimes the translation is ambiguous, but in those cases I can immediately refer back to the original English. This has been a major help to me and to other Korean developers I work with.

I'm using it 50% English (personal projects)/50% Polish (workplace; reasons being agents.md / team is not that english proficient) and honestly I haven't seen much difference in the output/ambiguity.

Polish prompts tend to be shorter due to the language having a lot of verb forms/conjugations, the only "bad" thing for me is that when it's saying "it broke" it tends to use uncanny / blunt words that make me sometimes laugh.

Natural language doesn’t have the precision required for building systems. We already have languages for specifying systems precisely. It’s called “code”…

I think it will eventually be its own dialect of English. Telling LLMs what to do is better using not quite normal English and I think this will continue until it isn't recognizable as natural English anymore, but a new fuzzy programming language (probably >1).

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.

I'm using it in english / albanian. Not much difference really. Impressive.

I use French nearly all the time, it works well. Not that I can't write English prompts, but I find it easier to use my native language.

I'm teaching my kids to be fluent in tokenese

I agree, and those are still too focused on code generation for specific languages are fighting the last war.

It is the revenge of UML modeling.

Eventually it will get good enough that what comes out of agent work, is a matter of formal specification.

Assuming that code is actually needed and cannot be achieved as pure agent orchestration workflows.

You really think that's what the positions on either side boil down to, how they feel about expressing themselves in English vs C++? No, that's ridiculous. That's such a wild reductionistic simplification.

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.

These tools let you get a massive codebase functional in 6 days. But, presumably, there's no better language to target than Rust (in terms of safety/performance), and therefore the rest of time can be spent making the birthed-in-6-days codebase better.

But the author said "the code truly works, passing the test suite on Linux and soon other platforms" which just sounds really wise.

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.

This is the kind of program that would need to have a lot of unsafe even if it had been written in Rust from the very beginning. For comparison, there are about 2600 unsafe blocks in Deno, not counting dependencies.

> 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+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?

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.

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.

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

I have some experience in this. Reach out (email in my bio) I would love to chat.

A SMT solver may work better.

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

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.

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?

Nobody knows. Here's my two cents.

Zig is a very interesting LOW level language, but honestly I think it should be considered for what it is: a better C. I don't think it fits for anything that someone would have written in C++, Java, Haskell or C#. Instead, Rust is competitive with all of these languages when it comes to safety, abstractions and speed. And also C and Zig itself.

Zig has a couple very interesting ideas that make it stand out: comptime and the zig build system.

Alas, Zig is still far from being stable. Rust came out to the public in 2012 and became stable (1.0) in 2015. Zig came out to the public in 2016, and it's 10 years now and someone says it's still years away from 1.0.

So, while rust took 3 years of public development to become stable, zig is taking 10/15 years. I love the language, but TBH I don't see a great future ahead, especially with LLMs advancements that can use safer languages to do the same work. There's no point in risking more memory bugs when the effort for writing code is the same.

Honestly I think, at least to the Zig community, But isn't the biggest name we'd think of. There's been some philosophical friction between the Zig project and Bun (Zig is pretty anti-AI and favor methodical thinking through of problems, while Bun is more move fast and break things). I think TigerBeetle is a better representation of what Zig can do. TigerBeetle is fuzzed within an inch of its life, and is absolutely rock solid. The people who work on it are brilliant programmers who care a lot about correctness. They find that Zig lets them express their ideas succinctly, while still giving them the needed power.

When I read about Bun, I get the sense that Jarron has different priorities, mainly moving quickly. Bun also implements a lot of userspace APIs, since the core engine is JavaScriptCore which is written in C++. I think Rust really shines in applications programming, so I guess it makes sense that Rust has lined up with Jarron's needs. I'd be interested to see what JavaScriptCore would look like in Zig versus Rust, I think Zig might have an edge in the core interpreter and JIT.

It means nothing for Zig. Zig isn't even out of beta yet.

This is like when Aaron ported Reddit over from Lisp to Python

meaning it doesn't matter except for online discourse about X being bad for 2 days

Jarred has already said on Twitter that this was only an experiment for comparisons and very, very unlikely that they'd switch to Rust.

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.

I think you overestimate the number of people who care how the software (or any product really) they use is made.

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.

That is actually what companies like IBM and Unisys are already doing today, LLM assisted porting.

https://research.ibm.com/publications/enterprise-scale-cobol...

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).

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.

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.

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.

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?

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.

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

Kind of the opposite, I was deep in the R world a decade ago and there was a huge trend of replacing Java dependencies with C/++ ones because the JVM was such a pain to manage. The community eagerly adopted the replacements about as soon as they existed.

Notably, Bun is not a JS engine. JavaScriptCore is the JS engine. Bun is just a complicated wrapper around it.

> 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-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.

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.

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.

Bun is owned by anthropic and so has access to Mythos & unlimited tokens.

The answer is... more than any of us could likely afford.

also feels like a good posttraining task

At 100 agents in parallel that’s 4loc/min, and 100 agents is a lower bound on what they had access to.

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?

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.

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

Your guess is correct! Congrats. Bun itself is not GPL either by the way. Oh, rust compiler itself isn't GPL either.

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.

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.

Almost all of Bun's tests are written in JavaScript run in Bun itself.

@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.

Perhaps you can elaborate on how your comment is relevant to the Bun's experiment here.

It’s relatively easy to get a basic Unix-liked kernel together. Hardware compatibility (and associated testing) is where it gets hard.

They're not rewriting zig. They're rewriting bun, which is currently written in zig

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.

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/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!

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.

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.

Obviously LLMs would identify as binary.

(But also, low effort meanness is bad, HN strives for better in both dimensions)

> 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.

Thats true, but the author might have decided on its own. Not everything is a marketing plan.