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.

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.

undefined

Right. Previous discussion:

https://news.ycombinator.com/item?id=48841676

were you already doing production-ready changes to postgres in C?