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.
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.
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.
Comments
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".