Hacker News Reader

Comment by loufe | Hacker News Reader

Why program greenfield in C++? I know "made with rust" is a meme but seriously, why not a memory safe language in 2026?

The main reason was due to a much easier tight-integration with the DuckDB internals, so we can take the most of the DuckDB engine (and existing code) to use. As the extension must interact with table scanners, casting functions and whatnot.

However, DuckLake doesn't need to be implemented in C++ at all, I believe that whatever fits the engine that will be performing the reads/writes in Parquet and the connectors for the DBMSs should be a good fit.

For example https://github.com/borchero/ducklake-sdk - Rust https://github.com/datafusion-contrib/datafusion-ducklake - Rust https://github.com/motherduckdb/ducklake-spark - Scala https://github.com/brikk/trino-ducklake - Kotlin

Disclaimer: I'm the lead developer of DuckLake.

DuckDB has been around since 2018. Naturally its offspring use C++.

Rust has been out since 2010. It already was rated "most-loved" by 2016. Systems programmers had adopted it by 2018.

And the compiler was horrendously slow for big projects on x86_84 until 2023.

There is nothing stopping creation of rust implementations of tools or things that support these specs and protocols. But in DBMS world the centre of gravity is C/C++ mostly with some exceptions.

If I was writing a DBMS today, I'd consider Zig, never C/C++, as the latter continue to remain fraught with memory-safety footguns. So no, I don't concur with what's your center of gravity.

Fair enough. You wouldn't be the first (Tigerbeetle is famously implemented in Zig).

As someone who's personal spare time tinkering project is writing DBMS + storage engine in Rust I will say the language choice or it's memory safety is not that consequential.

If you're doing anything dealing with an actual storage engine you will be writing a bunch of unsafe code and using raw pointers all over the place. My hypothesis is once the guts are in place then I can go a lot faster with Rust but it's very much swimming against the tide and it is not magically safe out of the box once you are dealing with raw storage and paging.

But nonetheless if you go around the industry and do a count of commercial and Open source DBMS systems that have any kind of significant adoption it'll be about 95% C/C++ even if you filter to recent systems and there are legitimate reasons for that being a common choice.

TL:DR The hard part of a DBMS implementation is not picking the language

Reply on news.ycombinator.com