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

581–590 of 756 posts

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

#581

Post by ubercore »

ChadNauseam wrote: post #572
tosti wrote: post #560

Earlier quoted context omitted.

I started by looking at the dependencies. Then I lost count, so I ran wc -l Cargo.lock 1467 Cargo.lock Easily over a thousand dependencies. And "rewritten in Rust" is supposed to be a good thing? I bet this doesn't even compile faster than the original.

Do you pick your databases based on how quickly they compile and how many dependencies they have? I normally chose based on factors like performance and reputation for reliability

Reputation for reliability can be directly impacted by thousands of upstream dependencies, though.

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

#582

Post by ai_fry_ur_brain »

Jean-Papoulos wrote: post #504
sdevonoes wrote: post #251

Don’t understand these rewrites. - typically they are behind a single person. That’s usually bad because of spf - typically they are achieved in a very short amount of time, so the author hasn’t acquired any discipline in creating the project. That means it’s unlikely the author is going to stick to the project in the mid and long term - anyone that wants to contribute to the project needs to pay. Needs to pay tokens…

It's useful to show the actual team that it's possible. From there, they can make the decision of whether to go the bun route with more information.

The bun route == spending 100k for an LLM rewrite as an advertisement for the LLM company you sold your soul to.

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

#583

Post by 27183 »

cyphar wrote: post #518
IsTom wrote: post #339

Earlier quoted context omitted.

With programs large enough tests aren't going to ever be enough. Formal verification might work, but then who checks the specification for bugs?

I really wonder where all of these people who believe that tests perfectly encapsulate the behaviour of software come from. Maybe it's because LLMs happen to work better when you give them acceptance criteria and people struggle to distinguish between "better" and "good"?

The real test is years in production. Over time your test suite grows when bugs are found and fixed, but not every bugfix necessarily gets a test, and it's very rare that a bugfix is exhaustively tested. Relying on the test suite as a directional indicator that your vibecoded rewrite functions something like the original is probably sensible. But it isn't "done" until you've run it in production for at least as long as the original. And that's where it all falls apart, because maintenance will be a nightmare. Nobody knows how the new thing works.

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

#584

Post by davedx »

sdevonoes wrote: post #251

Don’t understand these rewrites. - typically they are behind a single person. That’s usually bad because of spf - typically they are achieved in a very short amount of time, so the author hasn’t acquired any discipline in creating the project. That means it’s unlikely the author is going to stick to the project in the mid and long term - anyone that wants to contribute to the project needs to pay. Needs to pay tokens…

This is very critical of an open source project that the maintainer didn't even post here?

"Status:

pgrust is not production-ready yet. It is not performance optimized yet."

The maintainer is not suggesting you use this for anything yourself. So why do you care about spf or (lol) his "discipline in creating the project"?

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

#585

Post by r_lee »

diziet wrote: post #576
kaoD wrote: post #545

Earlier quoted context omitted.

> I love llm coding. I don't know what I am looking at here There might be some correlation here.

I am fully aware what Cargo.lock is. What I am surprised at is how many dependencies there are.

it's like node_modules but cooler

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

#588

Post by tgv »

malisper wrote: post #187
tgv wrote: post #136

Earlier quoted context omitted.

It's not just unsafe, it's this: let r = unsafe { &*p }; It looks as if it's building structs out of information in (mutable pointers) to other structs without an Rc in sight. Which makes sense for a C parser: you've got a table with data, so you just link to it. It's fast, and when you know you're not going to touch it, it's safe. But this doesn't make the Rust code any better than the C code.

Note that the code I believe you are referring to is from the parser which was generated with c2rust. The Postgres parser is generated from yacc/bison so rather than try to rewrite it idiomatically, I did so mechanically.

Why not just link to the C code then?

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

#589

Post by cowboylowrez »

solid_fuel wrote: post #574
rjh29 wrote: post #548

Earlier quoted context omitted.

There are hundreds of comment chains about this already, go troll somewhere else.

If you’re going to make a confident blanket claim, be ready to back it up - and asking for clarification is not trolling, by the way. You should be ready to engage in technical conversations if you want to make technical claims.

There is an expectation that threads are more performant than processes all else being equal. Obviously there is some work involved to make "all else be equal", like maybe threads have less isolation from each other etc but if you can mechanically convert code to use threads where it used to use processes I can see the claim standing up.

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

#590

Post by christophilus »

ChadNauseam wrote: post #572
tosti wrote: post #560

Earlier quoted context omitted.

I started by looking at the dependencies. Then I lost count, so I ran wc -l Cargo.lock 1467 Cargo.lock Easily over a thousand dependencies. And "rewritten in Rust" is supposed to be a good thing? I bet this doesn't even compile faster than the original.

Do you pick your databases based on how quickly they compile and how many dependencies they have? I normally chose based on factors like performance and reputation for reliability

If a dependency gets compromised, that’s a problem. If you have thousands, you increase the odds vs if you have one.
Post reply on HN