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

81–90 of 756 posts

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

#81

Post by ottavio »

dixtel wrote: post #64
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.

> software talibans I will note that, very funny

Well, this approach is more similar to imposing a dogma thank engineering.

Is managing memory safely important? YES

Is managing memory safely the solution to most of the problems? Absolutely not.

Advocating the language ignoring everything else (having as first and only argument that the code was rewritten in rust fully qualify for this case) is dogma and not engineering.

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

#82

Post by [deleted] »

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.

[deleted]

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

#83

Post by cyberjar »

I'm starting to get a bit of fatigue for these projects that boil down to just "I asked Claude to re-write this code into a new language that's in vogue right now!"

I really don't understand why this is needed outside of an opportunity to show how impressive LLMs can be when working within large codebases, but even then people in the comments are finding bizarre implementation choices that a human developer wouldn't make. I'll stick with Postgres and its - gasp - C implementation for now, thanks.

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

#84

Post by nasretdinov »

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.

I can trivially copy any code even without an LLM though with a simple tool called rsync!

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

#85

Post by gb2d_hn »

kelnos wrote: post #34
sshine wrote: post #14

Earlier quoted context omitted.

> not mostly the test, but the real world production scars Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour. SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some gua…

Sure, but behaviors that never have a bug or regression don't get a test. Software of this kind of complexity has all kinds of behavior that has never been broken, and doesn't have a specific test written for it. Getting an extensive test suite passing is certainly orders of magnitude better than having no test suite at all, but it still doesn't tell you as much as you need to know. I would absolutely never trust an…

Agreed.And a rewrite in another language creates a high probability of a change in behaviour

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

#86

Post by tpetry »

kstrauser wrote: post #7
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.

In a project like PostgreSQL, those scars are reflected in unit tests demonstrating that they’re fixed. It’d be hard to pass its test suite and not be as robust as the original.

You immply that a testcase exists for every weird edge case. Especially filesystem and concurrency is things you can barely build test cases for.

Even a 100% test coversge is far away from verifying all behaviour.

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

#87

Post by zsoltkacsandi »

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.

Completely agree with this.

The biggest lie of software engineering is that everything can be testable with tests. That a 100% test coverage is an indicator of quality software.

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

#88

Post by nicce »

sshine wrote: post #14
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.

> not mostly the test, but the real world production scars Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour. SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some gua…

> Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour.

If you can be 100% guaranteed that there indeed is a test for every occurred bug. Sometimes maintainers are not so strict about it.

And some programmers are so good that some issues are self-explanatory and they write good code to note a thing but don't write a test, because implementing the test is more expensive.

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

#89

Post by queoahfh »

pdevr wrote: post #75
queoahfh wrote: post #50

What a peculiar kind of rewrite. Rust: https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... Original: https://github.com/postgres/postgres/blob/df293aed46e3133df3... Usage: https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... The return type in the rewrite is both some sort of Error tagged union that supports the Try machinery in Rust; but, it also contains a boolean that apparently must be chec…

It is a feature in Rust, not a bug :-) (I know you didn't say it is a bug.) The error-tagged union is PgResult - which means it contains bool as the result if things go well. (The other part in the union is of course the error.) In the original function also, it is returning a boolean: "bool has_subclass". So anyway you have to check for the boolean as part of the logic. That is what it is doing.

Yes, but the original boolean seems to have been used for error handling, and the tagged union is also used for error handling. Why have both simultaneously in the same function instead of just one of the two?

Edit: Looking at the code again, perhaps I was mistaken, since the boolean might not have been for error handling, just the result of the function, and C's limitations regarding error handling led it to using something like elog(), apparently a macro defined in https://github.com/postgres/postgres/blob/master/src/include... .

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

#90

Post by w4der »

bob1029 wrote: post #52
kelnos wrote: post #34

Earlier quoted context omitted.

Sure, but behaviors that never have a bug or regression don't get a test. Software of this kind of complexity has all kinds of behavior that has never been broken, and doesn't have a specific test written for it. Getting an extensive test suite passing is certainly orders of magnitude better than having no test suite at all, but it still doesn't tell you as much as you need to know. I would absolutely never trust an…

> Software of this kind of complexity has all kinds of behavior that has never been broken This space of things is astronomically larger than the space of things expressly covered by any test suite. "Program testing can be used to show the presence of bugs, but never to show their absence." -Edsger W. Dijkstra

I've also seen situations where a customer reports a bug, the fix breaks some regression, and the updated behavior to work around the fix breaking the regressions turns into an undocumented feature.
Post reply on HN