Re: [HACKERS] RustgreSQL - Mailing list pgsql-hackers
From | Craig Ringer |
---|---|
Subject | Re: [HACKERS] RustgreSQL |
Date | |
Msg-id | CAMsr+YFgZHFmtVGdU_o9Fw=YJP0ff=WrXd6gz+QqiXCikmeqCQ@mail.gmail.com Whole thread Raw |
In response to | Re: [HACKERS] RustgreSQL (Jan de Visser <jan@de-visser.net>) |
Responses |
Re: [HACKERS] RustgreSQL
Re: [HACKERS] RustgreSQL |
List | pgsql-hackers |
On 9 Jan. 2017 05:51, "Jan de Visser" <jan@de-visser.net> wrote:
On Sunday, January 8, 2017 6:28:17 AM EST Joel Jacobson wrote:And this is where I think you're wrong, and why conversion would be hard. C
> I don't want to learn the complicated details of C, that's true.
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.
pgsql-hackers by date: