Recent and related: Zig → Rust porting guide - https://news.ycombinator.com/item?id=48016880 - May 2026 (540 comments)
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.
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.
This may be so, but LLMs are great at slogging through such tedious repercussions.
I would say if the language prevents sloppy intermediate states, that actually makes it more amenable to AI; if you just half-ass a refactor into a conceptually inconsistent state, it’s possible for bad tests to fail to catch it in Python, say. But if many such incomplete states are just forbidden, then the compiler errors provide a clean objective function that the LLM can keep iterating on.
Are you saying this out of personal experience or just hypothesizing? I am working on a large, complex rust project with Claude Code and do not experience this at all.
I haven't had any issues with this getting out of hand on >10KLOC vibed rust codebases.
The lesson here is that right now LLMs are a lot better at "fill in the implementation for this API I defined" than "design everything from scratch" if you care at all about whether it becomes a mess of spaghetti. Maybe someday they'll be better at it, but at least today, you have to choose between going full vibes and not caring about the code, or you need to be involved in the design, and either way it's not clear that Rust is a significantly worse choice based on anything other than your own experience.
Example of a Claude Code session after 2 hours of "Crunching" that came out without results 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.
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...
You use the test suite and LLMs are trained on Postgres.
Are you at Freshpaint? A company that "helps healthcare marketing teams grow in a world where privacy is the baseline, but performance is the goal."
Nice promises! Surely the marketing teams will respect privacy!
curious about your workflow for running all these accounts. different harnesses in parallel? manually switching in codex? 5.5pro only?
what works for you?
Left to itself, it often follows human developers who conceive of their goal as "get the program working, the end justifies the means." Which makes sense because there are a lot of systems like that in the training corpus.
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.
Pretty impressive that it is faster than the Go version already.
It's much faster in single file benchmarks (3 to 5x)
https://tsz.dev/benchmarks/micro
I have optimizations planned for large projects that I'm still flushing out.
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.
Also remember, `cargo check` is quite fast, and wholly sufficient for confirming correctness.
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.
> 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.From your post, though, it sounds like Bun may have been a pretty direct rewrite, without too many hard choices along the way. Is that fair?
This would not have been possible 5 years ago. LLMs are going to push us into the space age. Both Anthropic and OpenAI have committed to spending 10s of billions of dollars on training alone for the year. I am equally excited and terrified at the pace of progress!
Perhaps 16,000 could just measure cascade breakage, for example one lifetime mismatch can cause errors in every function that tries to use that reference.
Rust reference lifetime bookkeeping is a difficult task for LLMs. The LLM has to maintain, across multiple functions and structs, which references outlive which. Furthermore compiler messages are highly contextual and lifetime patterns are sparse in the training set.
Basically we are seeing now an "inverse Hofstadter's Law" where doing something with an LLM takes less time thanexpected even when you take into account this law.
I am a Rust developper myself but I really love Zig and Bun. I am just overly curious of all this.
haven't used zig...(only used rust)
but zig doesn't solve those problems?
Bun: Hold my beer
The AI companies and their associates are beginning to surpass that level of denials and lies.
would the world come to a standstill tomorrow if every Bun instance out there ran on Node.js ?
they know their A.I can't sell without the noise that it's now on the edge of the frontier. this is hype.
zig adopting a strict 'no LLM' policy affects the LLM vendors.
> 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.
Let's take this to a different domain, self driving cars. Would you equally argue for human driving? I'm pretty sure over time it will become clear to everyone that machines will be able to outperform humans consistently at this task, to the degree that human driving will become illegal. But for now the press likes to focus on any failure of machine driving, taking for granted human drivers are the largest or second largest cause of premature death in many countries.
Coding (in many ways, but not all) is a more open ended and versatile task than driving, so it's natural that current iterations seem untrustworthy, but ignoring the trajectory is erring on conservatism, and doesn't seem to me to be grounded in any sound reasoning.
Seems like that would make open source entirely controlled by open ai, anthropic et al.
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
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
https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
119 open, 885 closed
https://github.com/denoland/deno/issues?q=is%3Aissue%20state...
10 open, 46 closed
> 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.
Not a hard number obviously but a clear indication those issues exist.
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.
What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.
While bounds checking, improved argument passing, typed pointers, proper strings and arrays are an improvement over C, it still suffers from use after free cases.
C++ already prevents many of those scenarios, at least for those folks that don't use it as a plain Better C, and actually make use of the standard library in hardned mode. When not, naturally is as bad as C.
Also to note that the tools that Zig offers to prevent that, are also available in C and C++, but people have to actually use them, e.g. I was using Purify back in 2000's.
Then there is the whole point that Zig is not yet 1.0, and who knows what will still change until then.
They're difficult to find, difficult to reason about in big software and you'll always create some. Languages that rule that out are a huge improvement in terms of correctness.
This is a classic logic problem - eg “there is an orange cat” doesn’t imply “all cats are orange”.
plenty of other companies/entities making high quality software in zig? tigerbeetle, zig itself for example.
Bun's entire history has been a kind of haphazard move as fast as you can story, so...
There’s a lot of leaky crap written in those languages too. One of the core promises of Rust is that the compiler will catch memory issues other languages won’t experience until runtime. If Zig doesn’t offer something similar it’ll make Rust very compelling.
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.
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
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://bun.com/blog/bun-joins-anthropic
I'm not sure if the 50% of people defending the whole rewrite live under a rock with regard to the acquisition or have never worked at a US company or a deliberately naive. Companies give instructions. Nothing of this is accidental or prompted by curiosity.
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.
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?
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.
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.
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.
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.
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.
In the US, (nearly) full electrification wasn't achieved until the late 1940's/early 1950's - a process of nearly a century. (A moment of personal trivia, my great grandfather worked on crews electrifying rural areas of the midwest.)
Energy costs vary widely across the world and that has enormous capacity for the economies of different countries and their industrial capacity.
These models are a race to the bottom just like compute.
This is both amazing and scary; has been for a while now.
45 million lines would get to ~$1.125 mil for the linux kernel.
950k lines for Bun would get to $23,750
use whatever math you like ofc.
Does an Anthropic/employee pay that, no. Even if it's at a loss in terms of company revenue, it's worth burning the private capital for all kinds of other reasons.
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.
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.
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.
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.
Few big popular projects use Zig, if they start to move away from it, what Zig's future will look like?
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.
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.
meaning it doesn't matter except for online discourse about X being bad for 2 days
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?
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.
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.
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).
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.
Ignore the hundreds of thousands of hours put into the original architecture and test suite that made it possible in the first place.
https://blog.katanaquant.com/p/your-llm-doesnt-write-correct...
Claude code C compiler passed 100% of gcc tests and couldn't even run a hello world...
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
LLMs work best when the user defines their acceptance criteria first - https://news.ycombinator.com/item?id=47283337 - March 2026 (422 comments)
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.
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.
Not sure that rule is even applicable anymore, but I don't have a better heuristic to make guesses by either.
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?
I don’t see how this is a good look for Bun?
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.
> 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.
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.
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.
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.
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.
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.
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.
Node beat Deno and Bun. Pretty impressive.
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.
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...
Lets see the fruit of their decision.
We always think it’s not gonna hit us… we may be wrong
https://research.ibm.com/publications/enterprise-scale-cobol...
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?
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.
But the effort is certainly an exquisite rearrangement of the deck chairs, no?
bun script.ts just works.
Otherwise I bet it wouldn't even be a blip in our radar.
That said, yes, you’re correct that Bun isn’t GPL: https://github.com/oven-sh/bun?tab=License-1-ov-file
But in all honesty, I don't understand the extremism in Rust engineers that reject any other language.
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'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.
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.
Bun powers Claude.
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
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.
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.
Thanks for the sharing
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
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
More interestingly: will we need to care about the code at all, at that point?
The answer is... more than any of us could likely afford.
(in a VAE-ish way, kl div on the embeddings?)
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.
"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.
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.
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!
If this succeeds, there is no stopping AI given it will have crossed the rubicon of human bottlenecks.
---
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.
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.
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.
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?
The Rust rewrite now passes 99.8% of Bun’s pre-existing Linux x64 glibc test suite.