113 comments

[ 3.2 ms ] story [ 81.5 ms ] thread
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.

[flagged]
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.

It's a new era of capital, literally, in software development. Ownership of the means of production is now concentrated.
There are not many companies that live off taking full test suite made over decades and just generating code off it.
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.

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.

Good enough for a side project, not good enough for transferring banking system from cobol
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?

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

It’s pure marketing. Don’t be naive
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.
What license is this ? Let me guess, its is no GPL...
Interesting! I wonder how the performance is compared to the Zig version
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.
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?

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

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

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.
Can you or someone shed some light on how much compute it took to do this?
> 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.

From 4 days ago: 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.
He works at claude, he has unlimited tokens. He can do anything, he is using mythos.
what one has to do when corporate does not not them use GPT-5.5
I think such re-implementations will be a huge asset to the process of software developments in the future.
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

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

Being anthropic accuired project does he have access to mythos or it’s normal Claude we plebs have access to
Curious how the test suite was applied. Was it ported from Zig to Rust beforehand?
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.

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

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

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

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.

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

In my experience with Claude Code, it writes most of the code, including tests, without invoking the compiler until the very end (almost like a spelling checker). Rarely are there any compilation problems, and when there are, it’s often a token issue like a missing brace. I hypothesize this is possible because of the robust invariants of the language itself, and its strong types, such that the LLM can encode deeper meaning in fewer tokens.

Also remember, `cargo check` is quite fast, and wholly sufficient for confirming correctness.

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

Interesting, but why not then use an even stricter language? Say Idris, ATS, Lean or F* ?
Not OP. For this particular use case, I think performance is a primary concern.

But if you mean in general, I also totally feel that languages that let you represent more invariants statically are better fit for LLMs. I'd love to see experimentation with LLMs with dependent types and managed effects.

Because I don't know those languages. I'm still reading the code LLM writes