Re: Support for Rust

From: Lev Kokotov <lev(at)hyperparam(dot)ai>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support for Rust
Date: 2022-09-12 14:57:31
Message-ID: CANvSX4w1+3ZhMVcJdMic_Wz5d0tWwwYRs0HnrVVE4fiXgJR5pQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> You can write Postgres extensions in Rust. And Postgres extensions are
really powerful. What kind of features are you interested in?

Agreed, I've been writing one in Rust using tcdi/pgx [0]. Some features
can't be done there though, e.g. adding ON CONFLICT support to COPY.

> 1. Is Rust compatible with Memory Contexts and shared memory constructs
of Postgres? With elog error reporting, PG_TRY() and his friends?

Not to my knowledge. Just by reading the implementation, jumping to
arbitrary positions in the code is against safe programming that Rust
guarantees.

> 2. Does Rust support the same set of platforms as Postgres? Quick glance
at Build Farm can give an impression of what is supported by Postgres.

Rust compiles to LLVM, so the platforms supported by Rust are roughly the
same as LLVM. The list is large, but smaller than GCC. There is a Rust GCC
frontend in the works and the number of Rust targets is also increasing
including embedded [1].

> 3. Do we gain anything besides compiler hints? Postgres development is
hard due to interference of complex subsystems. It will be even harder if
those systems will be implemented in different languages.

Rust gives many things we wanted for decades:

1. No undefined behavior
2. No memory leaks, guaranteed at compile time
3. RAII - no surprise NULLs, no segfaults
4. "Zero-cost abstractions" - simple looking and otherwise expensive code
(e.g. generics, collections) is optimized at compile time and has no
runtime cost
5. Find bugs at compile time instead of runtime

Rust also has a large and ever growing community, and a great
cross-platform package manager and build system (cargo).

> There was some discussion about Rust back in 2017 [0] that you might be
interested in.

That was a good discussion. My takeaways are:

- Suggesting that someone else should do the work is a bad idea (I agree)
- This should be done by both C and Rust experts
- It's hard to find a good starting point and build momentum
- C++ is the favorite at the moment

Well... at the risk of embarrassing myself on the internet, I tried it this
weekend: https://github.com/postgresml/postgres/pull/1

I took a small part of Postgres to get started, so just as a PoC; it
compiles and runs though. Larger parts will take more work (deleting code,
not just swapping object files), and more fancy things like PG_TRY() and
friends will have to be rewritten, so not a short and easy migration.

Best,
Lev

[0] https://github.com/tcdi/pgx
[1] https://docs.rust-embedded.org/book/intro/index.html

On Sat, Sep 10, 2022 at 10:15 AM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:

> On Fri, Sep 09, 2022 at 07:38:14PM -0700, Lev Kokotov wrote:
> > Are there any plans or thoughts about adding support for other languages
> > than C into Postgres, namely Rust? I would love to hack on some features
> > but I worry somewhat that the C compiler won't give me enough hints that
> > I'm doing something wrong, and the Rust compiler has been excellent at
> > preventing bugs.
>
> There was some discussion about Rust back in 2017 [0] that you might be
> interested in.
>
> [0]
> https://www.postgresql.org/message-id/flat/CAASwCXdQUiuUnhycdRvrUmHuzk5PsaGxr54U4t34teQjcjb%3DAQ%40mail.gmail.com
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2022-09-12 15:03:43 Re: pgbench: using prepared BEGIN statement in a pipeline could cause an error
Previous Message Peter Eisentraut 2022-09-12 14:51:57 Re: list of acknowledgments for PG15