Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

github.com

Post reply on HN
Print view View original

151–160 of 756 posts

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#151

Post by nextaccountic »

gingersnap wrote: post #3

I start to see a lot of these re-writes that depend on tests to state that its working. But the things that make software like Postgres and SQLite reliable are not mostly the test, but the real world production scars. That's where the reliability comes from, years and years of running in production.

> I start to see a lot of these re-writes that depend on tests to state that its working.

There's another way to validate the rewrite though. Just run both pgrust and postgres and compare the output. Know of an edge case? Run it too. Doesn't know? Use a fuzzer or some automated tool to find interesting inputs. Found an inconsistency? The input/output pair becomes a test case now

Not sure if there's tooling for that though. If there is, just give it to Claude so they will incorporate it in their development loop

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#152

Post by EDM115 »

dirkc wrote: post #78

How would one go about reviewing a piece of code like this? One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you mu…

> How do you easily get to the first commit in a repo on GitHub?

You can use the syntax github.com/user/repo/commits/?after=last_commit_hash+number_of_commits-2 (-1 for the latest and -1 for the last)

ex : https://github.com/malisper/pgrust/commits/?after=3646a73515...

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#153

Post by jiggawatts »

CamouflagedKiwi wrote: post #133
arka2147483647 wrote: post #79

Earlier quoted context omitted.

Often the biggest blocker on moving to a new programming language, is the cost of re-writing everything. Cue some story here on a bank or airline somewhere still relying on cobol backend servers. These LLM conversions really seem to make modernization of large parts software layers possible!

I have some familiarity with the bank situation, and while a lot of them are on some very old systems (maybe COBOL, maybe something else, either way they want off it) the cost of actually re-writing the code is far from the most significant issue. Consider: You have a big mainframe running your tier 1 bank. Assume that you can see all the code on it, and you can feed all that to an LLM if you like. Getting it to spit…

> while you could ask your LLM to do that you aren't going to run your bank on the result.

Why not?

I feel like we're entering a new era of prejudice against not a category of humans, but against non-human intelligences.

The design patterns for distributed and fault-tolerant systems are well-known and established in the industry. Both humans and AIs are familiar with them!

So if you sketch a design for the AI to follow, establish the rules in AGENTS.md, have a robust test suite, use a frontier model dialed up to eleven, etc... why not rely on the LLM output?

At the end of the day, humans are not without fault either.

I've been wading through some legacy "pre-AI" code recently and it has more bugs than a rainforest! Static fields used incorrectly, causing data races. Floating point types used for money amounts. JavaScript and SQL injection up the wazoo. Wildly unsafe password handling. So on, and so forth. This is the norm for most human-written software, not the exception.

As a proof-of-concept, I tried an AI rewrite of one such legacy app[1], and it is not bug free, but it notably has fewer bugs than the original. Different bugs, sure, and I'll have to iron them out after a round or two of UAT, but I'm honestly more confident with what I got from the chatbot than the code inherited from humans.

[1] Deals with money, but admittedly at a much lower level of risk and consequence than a banking app running on a mainframe.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#154

Post by Leynos »

queoahfh wrote: post #22
colordrops wrote: post #6

Earlier quoted context omitted.

Is there any measurable difference in quality between the two, or are you just going on "vibes"? Is there a correlation between the quality of the manually written code and AI generated code driven by the same dev? Such crude takes only cause unnecessary friction. If you have a black box that spits out code, and you are unable to distinguish the quality between a top tier dev and an AI inside the black box, then the…

Didn't the initial rewrite of Bun into Rust have an ocean of "unsafe" in it, and wasn't it entirely dysfunctional?

Yes, that was the point. It made unsafe behaviour visible in a way that could be addressed. I hadn't heard any reports of it being dysfunctional.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#155

Post by shawabawa3 »

ottavio wrote: post #33

Why should a developer use this for anything beyond a pet project? Just because it is written in Rust? All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.

> Why should a developer use this for anything beyond a pet project?

If it _is_ 50% faster, then that's the reason

Obviously like any new database it's very risky to use so probably only used for niche use cases at first, but if it turns out to be just as reliable as postgres and faster then why not?

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#156

Post by nextaccountic »

OtomotO wrote: post #92
rytill wrote: post #71

Earlier quoted context omitted.

LLMs learn a distribution during pre-training, not only an average. Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned.

> Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned. How do you derive that something is "below average" or "average" or "above average"?

> How do you derive that something is "below average" or "average" or "above average"?

One technique is RLHF: have an human expert assess it.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#157

Post by alirezaxdehghan »

piker wrote: post #58
josefrichter wrote: post #47

Why so much negativity? I find these projects interesting for learning purposes and exploring new ways. What’s wrong with that?

Because it’s uncomfortable to see decades of work copied so trivially.

Imagine the feelings of a dude who used to code in assembly and then some punk writes in c++ and uses gcc... decades of work wasted.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#158

Post by dirkc »

bakugo wrote: post #104
dirkc wrote: post #78

How would one go about reviewing a piece of code like this? One of the things I'd typically do is peek at the commit history. Seeing what people worked on and how they did it tends to say a lot about a project. But with LLMs generating 7101 commits in less than a month that isn't feasible. Even looking at a single day is way too much [1]. It probably also doesn't make sense since the commits content won't tell you mu…

Vibe code was never meant to be reviewed. These rewrites are just test-driven development taken to the absolute extreme. Created under the hope that the existing tests are exhaustive and cover every relevant use case, such that if they all pass, the rewrite must be at least as good as the original. So just go with the vibes and burn tokens until they pass, and your job is done. In practice, this is never true for any…

The challenge is that more and more people are producing project like this - 1,000s of commits and > 200k lines of code - and saying it was carefully created using agent based workflows and not vibe coded.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#159

Post by bozdemir »

raincole wrote: post #37
bozdemir wrote: post #35

Earlier quoted context omitted.

I'd %100 prefer an opus 4.8 rewrite over %99 of the time. Unless Fabrice Bellard is rewriting the stuff I need, I'd prefer AI over a human coder.

Or, you know, you can use Postgres. It's right there for you.

why? if a rewrite is better/faster/secure, why not? (I'm not saying PGrust is better, I didnt even install it, my perspective is in general)

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#160

Post by malisper »

queoahfh wrote: post #62
znpy wrote: post #55

Is this another llm-driven rewrite? I wonder how many "unsafe" blocks are in there...

From what I skimmed manually, not that many, but the code itself seems labyrinthical. Like, why have both Rust Try-supporting Error-like tagged union, but also booleans, for error handling, in the same function? https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

I'm not sure what you mean? The rust code you're showing mimics the Postgres code: https://github.com/postgres/postgres/blob/2e6578292a9184dcaa...

The boolean being returned is the return value of the function. It's not used to return an error.

Post reply on HN