As a Postgres user, I like the idea. But their post comes off sounding like a JS dev wanting to rewrite an app in the latest popular language.

In this case there are potential performance and safety improvements by rewriting things in rust, the exact opposite of a JS rewrite.

Why would Rust be faster than C?

And, is potential safety 5+ years in the future (that's an absurdly optimistic estimate of a rewrite for an OSS project the size and scope of PostgreSQL) worth effectively standing still for all that time? Is the security/stability history of PostgreSQL poor? I'm not under that impression.

Rust isn't inherently faster than C, but it can be easier in some cases for the optimizer to optimize Rust code better than C code. In particular, I have in mind Rust's reference types and the fact that they all "follow LLVM’s scoped noalias model"[1]. You can, of course, get this same benefit in C by using restrict, but most of the C code I've seen makes little use of restrict (and it's quite easy to accidentally alias a restricted pointer, so it definitely imposes a mental burden, even if it's very slight).

Rust's safety model allows you to get the optimization of C's restrict without the footgun. That can be a big win.

But of course, just because something is written in Rust doesn't mean it'll be faster than the equivalent C code. Rust isn't magic, after all.

[1]: https://doc.rust-lang.org/reference.html#behavior-considered...

This has been touted, but has there been a non-trivial project that shows this? Something like a media manipulation library where there are lots of places for optimization. It's been stable for a few years now, so I imagine someone's seen performance benefits if it's happened.

Furthermore, given a team of experts working for half a decade on the rewrite, do we really believe it would yield safer code than if we spent the same amount of work on improving postgresql security?

I get the appeal of Rust for a new project though, especially if your team doesn't consist of seasoned C programmers.

Nobody is suggesting complete rewrite, but theoretically - yes, in terms of security rewriting in rust would be better investment than whack-a-mole game of chasing bugs in C.

Borrow checking means much less defensive copying without a loss of safety.

That's why I said potential. One reason would be the potential for much more asynchronous code than is easy to achieve in C, another would be Dev time. But the point is, rust is competing for speed with C, JS never was.

And that's missing the point of the analogy, whose focus is on "inexperienced developer" and "language du jour".

I belive that this reply says it all

    > Well that's going to be a show-stopper right there. For a proper 
    > port, a deep understanding of the current source code is necessary.
    > You'd need a team expert in both C and Rust to pull it off.

Also, they don't seem to understand that Corrode doesn't generate idiomatic Rust, nor does it remove the "over-complicated details of C". From the Corrode README: "This tool does not fully automate the job because its output is only as safe as the input was; you should clean up the output afterward to use Rust features and idioms where appropriate." So keeping the Rust rewrite in sync with the C codebase via automatic translation with Corrode is mutually exclusive with actually rewriting it in safe idiomatic Rust.

The weird thing is that they clearly have the sense to recognize that a rewrite would be a non-trivial project, but they seem to completely misunderstand why.

Add to that that you basically need to learn everything about C too when you learn Rust. C (without macros) is pretty much a subset of Rust, and there's a lot to learn on top of that subset. The advantage of Rust is not that it's easier, it is that you will more likely get a compiler error than a (possibly hidden) runtime bug if you don't have fully understood something.

> C (without macros) is pretty much a subset of Rust

Well, yes and no.

On the one hand unsafe Rust is roughly similar to C[1], and unsafe Rust is a subset of Rust. But unsafe Rust is not the most widely used subset of Rust, stable Rust is ! And stable Rust is arguably way easier to understand and work with than C. And you can write fairly complicated software without writing a single line of unsafe code.

[1]: even though, the more expressive syntax and type system of Rust makes a lot of things less error-prone in Rust, like pattern matching or Result<> for error handling instead of switch and goto.

Unsafe Rust is a _superset_ of safe Rust: it's the exact same thing, with some extra abilities. For that reason, "roughly similar to C" is also not exactly true; unsafe Rust, for example, does not remove any safety checks, it gives you access to extra unchecked things. A reference inside of an unsafe block is still borrow checked. But you can also use a raw pointer, that isn't.

Thanks for your clarification.

Your dedication to provide answer and explanations to absolutely everybody everywhere on the internet is incredible.

How many people do you keep enslaved in your basement to do all that work ? :p

You're welcome. And I don't have a basement ;)

I think the author is making a good point but possibly couching it in the wrong terms: C shifts a lot of the inherent complexity of systems programming and manual memory management onto the programmer, with the language offering little to no assistance. If you squint hard enough around the reems of specification and piles of undefined/implementation-defined behaviour in innocuous places, the language itself might indeed be something you could call simple, but actually writing correct code in it is not.

There's a reason many, many person-years have been devoted to tooling: offloading as much of the "simplicity" as we can onto computers is the best way we know how to write correct C at scale.

(That said, PostgreSQL clearly works well enough and has a system for writing new code that works well enough, so proposing a wholesale rewrite into a different language seems... unproductive, even moreso than usual.)