[simonw]

I don't think it's care to categorize this as "a naive rewrite away from [Zig]" - Jarred has been immersed in this project for five years, got to benefit from everything he learned along the way and spent $165,000 of tokens on the most advanced coding LLM anyone has access to.

I expect if he'd spent $165,000 running Fable against the Zig version he could have got a 5% performance improvement, too.

[malisper]

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.

[nvader]

I hope that you're going to call it PostGrust.

[SwiftyBug]

Na, PostPostgres would be much cooler.

[agumonkey]

Then you'll have postgrest on postgrust

[egorfine]

I find it curious that people who take other's people product and rewrite in their favorite programming language still name their own creation the name of the original one.

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

[khuey]

If they did the opposite and called it Mygres or whatever people would give them shit for that too.

[psychoslave]

Maybe not everyone is utterly obsessed with vanity and its delusion?

[egorfine]

Then why use someone else's established brand for your toy project?

[psychoslave]

If this is still speaking about the Postgres rewrite in Rust, then naming it something like pgrust[1] makes sense for ease of discovery for anyone aware of these technologies.

[1] https://github.com/malisper/pgrust I guess

[xeromal]

Would love to follow your journey!

[malisper]

If you want to follow along, I've been writing about it on my blog (https://malisper.me/) an you can follow the github repo here: https://github.com/malisper/pgrust

[xeromal]

Bookmarked. I love ambitious projects like this. I'll check in!

[einsteinx2]

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

[cognitiveinline]

Fable is kind of fantastic on the difficult tasks. if it's something eithe rmodel can do then you can't see the difference. Fable also makes much less mistakes. It's a more relentless, proactive problem solver.

[steve_adams_86]

I’ve been noticing that it will test hypotheses for evidence frequently. I really like that. With Opus I have to instruct it with a skill to build prototypes, but Fable will do it and do it really well by default. Really nice detail. I’m guessing it’s part of the system prompt, but the higher capability paired with this experimentation lean makes it far better at planning and verifying.

[Philpax]

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.

[gwenzek]

That's not what the article says though. The size reduction was from extra linker flag for deduping code, and the speed gains from LTO.

They could have done the same in Zig, even though it probably shows cargo is better at this than build.zig.