Without commenting on Bun itself as a project, or the nature of the rewrite, it can't be good for Zig that a naive rewrite away from it fixed memory leaks, improved stability, shrunk binary size by 20%, and improved performance by 5%.
I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.
It's not great for Zig if you have to put in more work to end up at the same place efficiency-wise, especially for a language marketed at people who like to get the most out of their metal.
They could have done the same in Zig, even though it probably shows cargo is better at this than build.zig.
I've been working on a new rewrite that's focused on beating Postgres on performance. As of this morning I got to 100% of the tests passing and have meaningful performance gains over Postgres.
Like, you have now created your own new database engine that happens to be compatible with Postgres. Wouldn't you take an absolute pride in giving it your own name? Why call it "Postgres rewrite in <programming language>"?
[1] https://github.com/malisper/pgrust I guess
After having used 2 full weeks of 20x Max plan tokens on Fable over the weekend (coding all day Saturday and Sunday on a non-trivial project, tasks across full stack, mix of adding features, reviewing code, and fixing bugs), I’m confident if he’d spent $165,000 in Opus tokens the port would have gone more or less just as well (and probably for less than $165,000). Especially so with the system they set up with all the custom workflows, adversarial reviews, extensive test coverage, etc.
But I get your point is probably more about Jarred’s experience level and the high cost than the specific model used other than it being SOTA. I’m just being pedantic and feeling a bit disappointed with Fable’s real world performance after all the hype.
> I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.
Totally agree and in fact I’m sure it could be done with significantly less cost even if they stuck with Fable instead of Opus which I’m sure could also do it.
Let me save you time and tell you that C# and it's ecosystem is where you'll be happy.
But they wouldn't get a change to the structural issues that created the issues in the first place. They'd end up "ke[eping] fixing these kinds of bugs one-off in perpetuity".
That said, I think the parts around wanting to properly have memory safety guarantees rather than try hard & patch as issues are found is a more serious concern for Zig as those speak more to the design goals than the current implementation. "better safety than C while maintaining C compatibility" may not be a very compelling reason to chose Zig if other languages are able to do that portion better anyways, even ones without a GC.
But a lot of people have been saying this for sometime, Rust and LLM is a great match. A lot of friction of the language were smoothed out by LLM assisted programming.
Zig was the right tool to start, Rust is the right tool to finish.
Making something possible and refining something until it is high security and reliability are different problems. Zig is great, but for a JS runtime, I just don't think that's the best long-term fit.
I just haven’t found another language that just makes sense. Zig doesn’t hide anything from you
[1] For example, as a random sample, https://github.com/oven-sh/bun/blob/bun-v1.3.14/src/css/medi... -> https://github.com/oven-sh/bun/blob/4924862cffbf671792d47c92...
> I rewrote Bun in Rust using about 50 dynamic workflows in Claude Code run continuously over the course of 11 days.
> Excluding comments, Bun is 535,496 lines of Zig.
> How do you review a PR with +1 million lines added? How do you start to build the confidence needed to responsibly merge large quantities of LLM-authored code? A language-independent test suite with a million assertions, adversarial code review and when something does go wrong, fixing the process that generates the code instead of hand-fixing the code.
That’s vibe coding. This blog post is an ad for Claude, nothing more.
The code was generated by a LLM, and the output wasn't even read by its user. That's definitely vibe coding.
Translation does seem to be a strength of LLMs, and as they said in the post, the code at the function-level all still feels familiar to the team. They've also already moved users to the codebase without anyone noticing; that's a better result than typical vibe coding.
I'm not trying to spin up some kind of conspiracy theory here, but I'm not sure to what extent Anthropic does have any vested interest in this project (in fiscal terms at least) because the reputational fallout could be significantly delayed and might just not be big enough to matter.
That's a very big reason not to screw this up.
This is not an assertion you are qualified to make
> Go read any analysis of the Claude Code leak for proof
You seem to be implying that Claude code is unmaintainable. Yet they appear to be maintaining it just fine. Did I misunderstand your implication?
And the fact is that they are maintaining it and it is one of the most successful software products of all time and is earning them mountains of cash. By any metric it is a successful product. So obviously whatever they are doing is working.
They rewrote the entire thing with extensive LLM use.
It is abundantly clear that their idea of maintainable and yours probably don't match up.
It's apparently out there, shipped in the real world, with people saying it's good. I think it's a pretty clear win for them.
There are different definitions of "maintainable". It seems the prevailing culture at Anthropic is to not touch code manually anymore. So for them "maintainable" means the LLM can fix it.
Did you compare the code before/after? It's a mechanical line-by-line port, and most of the code is identical to the old version, just with Rust syntax. They have an example in the blog post.
More precisely speaking: GC languages are said to delay memory problems far beyond the horizon, which is often unreachable throughout the project's history. Zig can be a similar case.
Not sure why people use it.
That's because closely following PL theory isn't always the right goal for a language. Ergonomics and pragmatism are far more important.
Though ignoring all the PL lessons for the sake of "pragmatism" is just plain ignorance.
Rust has a quite solid theory backing. Zig has nothing interesting really: it's "vibe coded" by someone who was doing game dev or something like that.