Re: Support for Rust - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Support for Rust
Date
Msg-id 410f948373a3b52f02d3af704128201a88ce6417.camel@j-davis.com
Whole thread Raw
In response to Re: Support for Rust  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2022-09-12 at 11:29 -0400, Tom Lane wrote:
> > Rust gives many things we wanted for decades:
>
> > 1. No undefined behavior
> > 2. No memory leaks, guaranteed at compile time
>
> Really?  It seems impossible to me that a language that even thinks
> it can guarantee that could interoperate with the backend's memory
> management.  And that's not something we are interested in replacing.

It's a distraction to talk about rust's safety "guarantees" in the
context of this thread. #1 is partially true, and #2 is outright
false[1].

C interoperability is the most compelling rust feature, in my opinion.
C memory representations are explicitly supported, and high-level
language features don't impose on your struct layouts. For instance,
rust does dynamic dispatch using trait objects[2], which hold the
vtable along with the reference, rather than in the struct itself. And
a "Foo *" from C has the same memory representation as an Option<&Foo>
in rust, so that you get the type safety.

Of course, rewriting Postgres would be terrible idea regardless of the
merits of rust for all kinds of reasons. But writing *extensions* in
rust is very promising because of this C interoperability.

>
> Yeah, that's what I thought.  "Allow some parts to be written in
> language X" soon turns into "Rewrite the entire system in language X,
> including fundamental rethinking of memory management, error
> handling,
> and some other things".  That's pretty much a non-starter.

You may be surprised how much you can do with rust extensions without
changing any of those things[3].

Regards,
    Jeff Davis

[1] https://doc.rust-lang.org/std/mem/fn.forget.html
[2] https://doc.rust-lang.org/book/ch17-02-trait-objects.html
[3] https://www.pgcon.org/2019/schedule/attachments/532_RustTalk.pdf




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: make_ctags: use -I option to ignore pg_node_attr macro
Next
From: Matthias van de Meent
Date:
Subject: Re: Git tag for v15