Re: RustgreSQL

From: Craig Ringer <craig(dot)ringer(at)2ndquadrant(dot)com>
To: Jan de Visser <jan(at)de-visser(dot)net>
Cc: Joel Jacobson <joel(at)trustly(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RustgreSQL
Date: 2017-01-08 23:06:21
Message-ID: CAMsr+YFgZHFmtVGdU_o9Fw=YJP0ff=WrXd6gz+QqiXCikmeqCQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9 Jan. 2017 05:51, "Jan de Visser" <jan(at)de-visser(dot)net> wrote:

On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote:
> I don't want to learn the complicated details of C, that's true.

And this is where I think you're wrong, and why conversion would be hard. C
has very few complicated details. I don't think it has any, frankly.

Oh, that's really rather optimistic.

C is a small-ish language. But achieving a good understanding of its memory
model and its implications isn't easy at all. There is lots of undefined
behaviour in the language too, which makes it easy to write code that
works... mostly. Usually. Until you hit some edge case, run on a different
architecture/platform, etc.

Then the system libraries and their implementations add complexity. ptheads
may not be part of C but for many projects a solid understanding of them is
crucial... and not that easy.

Do you comprehensively understand the rules for memory ordering when
processes interact in shared memory? Can you explain the correct uses of
volatile and when declaring something volatile is / isn't sufficient for
ensuring safe concurrent access? What happens if you dereference a pointer
to a struct allocated on the stack of a just-returned function?

I had a quick look at Rust and it sounds like it tries to make this sort of
stuff simpler. I didn't see any formal definition of a memory model though
- it seems like it figures you'll just use its concurrency primitives. And
C looks simple enough at first too... emergent complexity from seemingly
simple rules is hard.

It is easy to write C programs of moderate complexity that work reliably
within tested conditions and are somewhat portable to a set of tested-for
architectures. It is very hard to write C that is generally portable,
robust in the face of various edge-case inputs and environmental
conditions, are free from race conditions and memory ordering problems, and
rely on no undefined behaviour.

This is only partly a deficiency of C. Lots of it is down to low level
systems being complex, hard and varied. Weak vs strong memory ordering,
LP64 vs ILP64, etc etc etc.

I know only just enough C to be dangerous. Admittedly I haven't adequately
studied the language, but I have some idea how much I don't know. I doubt
there are a lot of people who can write truly error-free C. But that's also
true of pretty much any language, even ones that purport to be safe.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-01-08 23:10:38 createdb warnings on OS X
Previous Message Gavin Flower 2017-01-08 23:05:38 Re: RustgreSQL