> The goal is to make Postgres easier to change from the inside <...>
Easier because it's in Rust and not in C?
If LLMs are good enough to rewrite C to Rust, why not just use it to change C directly?
Would be nice to see some research compairing LLMs performance on the "same" codebase where the only difference is the language.
ShinTakuya•1h ago
I don't support this idea of rewriting everything in Rust but the answer to your question should be fairly obvious. Rust that compiles will generally be stable assuming you don't do a bunch of unwraps and panics. C that compiles can seem fine until it isn't.
LLMs still aren't as good at detecting C memory management issues as an experienced developer. With Rust, that doesn't matter as much because generally the compiler will tell the LLM when it's wrong.
takamoto•59m ago
Your regression tests can't catch every type of pointer, memory and undefined behavior failure so passing the tests after a change means less if the language is C than if the language is rust since rust has far fewer allowances.
criley2•58m ago
>If LLMs are good enough to rewrite C to Rust, why not just use it to change C directly?
One part of how LLMs can deliver quality code isn't the LLM itself, but the environment. Linting rules, automated tests, compilers, or other tools that give the LLM feedback during agentic engineering.
Rust has a lot more feedback than C about memory safety out of the box, meaning that it's a lot easier for an LLM (or human) to write memory safe code using it.
mawadev•57m ago
They are large language models, they can translate very well, but they cannot form original changes without heavy supervision/review and indefinite feedback loops. Most of these projects you see are just a way to gather attention or justify technology that is flawed at a fundamental level for the use case it pretends to be good for. Rust in particular has a very strict compiler and a lot of tokens/language features/syntax that hint at specific behavior tightening the feedback loop.
Maybe I'm very uneducated on this, but what exactly is the problem with postgres in its current state? Why do you need rust to make changes easier?
The only justification I see here is this claim and it is nowhere published or verifiable:
"Update: We're working on a new not yet published version of pgrust that currently passes 100% of Postgres regression suite, has a thread per connection model instead of process per connection, is 50% faster than Postgres on transaction workloads, and is ~300x faster than Postgres on analytical workloads (2x slower than Clickhouse on clickbench and we think it can get faster than Clickhouse). Follow pgrust or join our Discord for updates!"
ottavio•1h ago
Again pgrust?
This is going tò look like The Revenge of Zealots...
ivanjermakov•1h ago
Easier because it's in Rust and not in C?
If LLMs are good enough to rewrite C to Rust, why not just use it to change C directly?
Would be nice to see some research compairing LLMs performance on the "same" codebase where the only difference is the language.
ShinTakuya•1h ago
LLMs still aren't as good at detecting C memory management issues as an experienced developer. With Rust, that doesn't matter as much because generally the compiler will tell the LLM when it's wrong.
takamoto•59m ago
criley2•58m ago
One part of how LLMs can deliver quality code isn't the LLM itself, but the environment. Linting rules, automated tests, compilers, or other tools that give the LLM feedback during agentic engineering.
Rust has a lot more feedback than C about memory safety out of the box, meaning that it's a lot easier for an LLM (or human) to write memory safe code using it.
mawadev•57m ago
Maybe I'm very uneducated on this, but what exactly is the problem with postgres in its current state? Why do you need rust to make changes easier?
The only justification I see here is this claim and it is nowhere published or verifiable:
"Update: We're working on a new not yet published version of pgrust that currently passes 100% of Postgres regression suite, has a thread per connection model instead of process per connection, is 50% faster than Postgres on transaction workloads, and is ~300x faster than Postgres on analytical workloads (2x slower than Clickhouse on clickbench and we think it can get faster than Clickhouse). Follow pgrust or join our Discord for updates!"