Why Is SQLite Coded In C • Hacker News Board

Re: Why Is SQLite Coded In C

#31

Post by slashdev » Tue, Oct 14, 2025, 11:51 PM UTC

This is ignoring the elephant in the room: SQLite is being rewritten in Rust and it's going quite well. https://github.com/tursodatabase/turso

It has async I/O support on Linux with io_uring, vector support, BEGIN CONCURRENT for improved write throughput using multi-version concurrency control (MVCC), Encryption at rest, incremental computation using DBSP for incremental view maintenance and query subscriptions.

Time will tell, but this may well be the future of SQLite.

Re: Why Is SQLite Coded In C

#32

Post by ChadNauseam » Tue, Oct 14, 2025, 11:53 PM UTC

bfkwlfkjf wrote: post #16

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy. Huh it's not everyday that I hear a genuinely new argument. Thanks for sharing.

I wonder if this problem could be mitigated by not requiring coverage of branches that unconditionally lead to panics. or if there could be some kind of marking on those branches that indicate that they should never occur in correct code

Re: Why Is SQLite Coded In C

#33

Post by zvmaz » Tue, Oct 14, 2025, 11:54 PM UTC

slashdev wrote: post #31

This is ignoring the elephant in the room: SQLite is being rewritten in Rust and it's going quite well. https://github.com/tursodatabase/turso It has async I/O support on Linux with io_uring, vector support, BEGIN CONCURRENT for improved write throughput using multi-version concurrency control (MVCC), Encryption at rest, incremental computation using DBSP for incremental view maintenance and query subscriptions. Time…

In the link you provided, this is what I read: "An in-process SQL database, compatible with SQLite."

Compatible with SQLite. So it's another database?

Re: Why Is SQLite Coded In C

#34

Post by jonahx » Tue, Oct 14, 2025, 11:54 PM UTC

bfkwlfkjf wrote: post #16

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy. Huh it's not everyday that I hear a genuinely new argument. Thanks for sharing.

So is the argument that safe langs produce stuff like:

    // pseudocode
    if (i >= array_length) panic("index out of bounds")

that are never actually run if the code is correct? But (if I understand correctly) these are checks implicitly added by the compiler. So the objection amounts to questioning the correctness of this auto-generated code, and is predicated upon mistrusting the correctness of the compiler? But presumably the Rust compiler itself would have thorough tests that these kinds of checks work?

Someone please correct me if I'm misunderstanding the argument.

Re: Why Is SQLite Coded In C

#35

Post by mellinoe » Tue, Oct 14, 2025, 11:55 PM UTC

mikece wrote: post #2

The fact that a C library can easily be wrapped by just about any language is really useful. We're considering writing a library for generating a UUID (that contains a key and value) for reasons that make sense to us and I proposed writing this in C so we could simply wrap it as a library for all of the languages we use internally rather than having to re-implement it several times. Not sure if we'll actually build t…

You can expose a C interface from many languages (C++, Rust, C# to name a few that I've personally used). Instead of introducing a new language entirely, it's probably better to write the library in one of the languages you already use.

Re: Why Is SQLite Coded In C

#36

Post by Cloudef » Tue, Oct 14, 2025, 11:55 PM UTC

metaltyphoon wrote: post #30

plainOldText wrote: post #4

I’d be curious to know what the creators of SQLite would have to say about Zig. Zig gives the programmer more control than Rust. I think this is one of the reasons why TigerBeetle is written in Zig.

> Zig gives the programmer more control than Rust More control over what exactly? Allocations? There is nothing Zig can do that Rust can’t.

I think zig generally composes better than rust. With rust you pretty much have to start over if you want reusable / composable code, that is not use the default std. Rust has small crates for every little thing because it doesn't compose well, as well to improve compile times. libc in the default std also is major L.

Re: Why Is SQLite Coded In C

#37

Post by tonyhart7 » Tue, Oct 14, 2025, 11:55 PM UTC

slashdev wrote: post #31

This is ignoring the elephant in the room: SQLite is being rewritten in Rust and it's going quite well. https://github.com/tursodatabase/turso It has async I/O support on Linux with io_uring, vector support, BEGIN CONCURRENT for improved write throughput using multi-version concurrency control (MVCC), Encryption at rest, incremental computation using DBSP for incremental view maintenance and query subscriptions. Time…

so its sqlite++ since they added bunch of things on top of that

Re: Why Is SQLite Coded In C

#38

Post by anitil » Tue, Oct 14, 2025, 11:55 PM UTC

bfkwlfkjf wrote: post #16

> Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy. Huh it's not everyday that I hear a genuinely new argument. Thanks for sharing.

It's the sort of argument that I wouldn't accept from most people and most projects, but from Dr Hipp isn't most people and Sqlite isn't most projects.

Re: Why Is SQLite Coded In C

#39

Post by metaltyphoon » Tue, Oct 14, 2025, 11:55 PM UTC

slashdev wrote: post #31

This is ignoring the elephant in the room: SQLite is being rewritten in Rust and it's going quite well. https://github.com/tursodatabase/turso It has async I/O support on Linux with io_uring, vector support, BEGIN CONCURRENT for improved write throughput using multi-version concurrency control (MVCC), Encryption at rest, incremental computation using DBSP for incremental view maintenance and query subscriptions. Time…

The moment turso becomes stable , SQLite will inevitably fade away with time if they don’t rethink how contributions should be taken. I honestly believe the Linux philosophy of software development will be what catapults turso forward.

Re: Why Is SQLite Coded In C

#40

Post by sedatk » Tue, Oct 14, 2025, 11:56 PM UTC

steveklabnik wrote: post #12

pm2222 wrote: post #6

These points strike me: Safe languages insert additional machine branches to do things like verify that array accesses are in-bounds. In correct code, those branches are never taken. That means that the machine code cannot be 100% branch tested, which is an important component of SQLite's quality strategy. Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. Rust ne…

If the branch is never taken, and the optimizer can prove it, it will remove the check. Sometimes if it can’t actually prove it there’s ways to help it understand, or, in the almost extreme case, you do what I commented below.

Yeah I don't understand the argument. If you can't convince the compiler that that branch will never be taken, then I strongly suspect that it may be taken.