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.
But this is Rust, not safe Rust, right? So, you still have a lot of ways to shoot yourself in the foot.
Of course, the C -> unsafe Rust -> safe Rust is more likely to happen than just going straight to (mostly) safe Rust (I doubt a 100% safe dbms would make sense).
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!"
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.
> 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.
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.
But this is Rust, not safe Rust, right? So, you still have a lot of ways to shoot yourself in the foot.
Of course, the C -> unsafe Rust -> safe Rust is more likely to happen than just going straight to (mostly) safe Rust (I doubt a 100% safe dbms would make sense).
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!"
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.
Passing every regression test is huge, but extension compatibility will probably be the real test for production adoption.
Again pgrust?
This is going tò look like The Revenge of Zealots...
Right. Previous discussion:
https://news.ycombinator.com/item?id=48841676
for me rust is more cognitive load than c, so you lost at least one to change it from the inside.
were you already doing production-ready changes to postgres in C?