[indogooner]

Can you point to some resources (discussions/blogs/papers) on these? I was under impression that the reason recent database kernels are in C++ is because the authors are more proficient in it which should change as Rust becomes more popular.

[jandrewrogers]

There is an element of truth that C++ is used because it is the default language for people that work on database kernels professionally but that doesn't tell the whole story. I've been party to multiple attempts to port or implement modern database kernel designs in Rust by people that also work on the C++ kernels. There are ordinary language friction issues since Rust is not as expressive as C++ for the kind of low-level memory manipulation commonly found inside database kernels, but that's not what's limiting use.

Two core design elements of modern database kernels create most of the real challenges. First, all references to most objects are implicitly mutable and some references are not observable by the compiler; safety can only be guaranteed dynamically at runtime by the scheduler. Major performance optimizations rely on the implications of this. Second, your runtime data structures don't have lifetimes in the ordinary sense because they all live in explicitly paged memory -- they aren't even guaranteed to have a memory address, never mind a stable one. And you want this to all be zero-copy, because performance. There are elegant ways of doing this transparently in C++ with a bit of low-level trickery, but it is antithetical to the way Rust wants you to manipulate memory. There are workaround options in Rust of course but they are strictly worse than just doing it in C++.

Database kernels are an edge case. Most systems software doesn't break most assumptions about ownership and lifetimes so pervasively. I expect Rust will add features over time that help in these cases.