> and spent $165,000 of tokens on the most advanced coding LLM anyone has access to.

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.

I can confirm a naive rewrite won't make things faster. I've been working on rewriting Postgres in Rust. I rewrote things function by function similar to how Jarred did. Even though the new Rust code mapped closely with the previous C code, it was 8x slower. This was due to myriad of reasons. For example naively converting a C union into a Rust enum can be slower because Rust stores a tag with the enum, while C unions do not.

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.

Oh, I have no doubt that they could have extracted those gains from Zig! My point is more that, from a relatively naive line-to-line port, they were able to claim these benefits without much effort.

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.

The stability gains are a direct language concern as mentioned throughout the article.

A sophisticated rewrite? Sure. This was a naive like-for-like rewrite, though.

I thought Zig was supposed to be a C replacement (as in, it doesn't actually provide full safety in the way that Rust or a GC language would)?

Maybe they'd get the same numeric improvements and bug fixes today (or maybe not, or maybe they'd get even more since the LLM isn't spending time rewriting correct code).

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

But how would you verify that the agents have written memory safe code? Rust's borrowchecker is a lot faster and actually verifiably safe compared to asking an LLM to fix the safety issues that the Zig version had.

>they turned it into something unreadable

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.

The article explicitly mentions the maintainability as a foremost concern.

I find Rust more readable than zig

I would be pissed if my programming language changed as quickly as Claude code does. Languages need to move slowly and carefully, and zig is on the faster end of language development regardless.