Why Is SQLite Coded In C • Hacker News Board

Re: Why Is SQLite Coded In C

#11

Post by steveklabnik » Tue, Oct 14, 2025, 11:05 PM UTC

rstuart4133 wrote: post #9

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…

> 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. This is annoying in Rust. To me array accesses aren't the most annoying, it's match{} branches that will never been invoked. There is…

A more direct translation of the sqlite strategy here is to use get_unchecked instead of [], and then you get the same behaviors.

Your example does what [] does already, it’s just a more verbose way of writing the same thing. It’s not the same behavior as sqlite.

Re: Why Is SQLite Coded In C

#12

Post by steveklabnik » Tue, Oct 14, 2025, 11:06 PM UTC

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.

Re: Why Is SQLite Coded In C

#13

Post by pella » Tue, Oct 14, 2025, 11:13 PM UTC

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…

Turso:

https://algora.io/challenges/turso "Turso is rewriting SQLite in Rust ; Find a bug to win $1,000"

------

- Dec 10, 2024 : "Introducing Limbo: A complete rewrite of SQLite in Rust"

https://turso.tech/blog/introducing-limbo-a-complete-rewrite...

- Jan 21, 2025 - "We will rewrite SQLite. And we are going all-in"

https://turso.tech/blog/we-will-rewrite-sqlite-and-we-are-go...

- Project: https://github.com/tursodatabase/turso

Status: "Turso Database is currently under heavy development and is not ready for production use."

Re: Why Is SQLite Coded In C

#14

Post by 01HNNWZ0MV43FF » Tue, Oct 14, 2025, 11:16 PM UTC

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…

But if you don't have the bounds checks in machine code, then you don't have bounds checks.

I suppose SQLite might use a C linter tool that can prove the bounds checks happen at a higher layer, and then elide redundant ones in lower layers, but... C compilers won't do that by default, they'll just write memory-unsafe machine code. Right?

Re: Why Is SQLite Coded In C

#15

Post by 01HNNWZ0MV43FF » Tue, Oct 14, 2025, 11:18 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…

It is. You can also write it in C++ or Rust and expose a C API+ABI, and then you're distributing a binary library that the OS sees as very similar to a C library.

Occasionally when working in Lua I'd write something low-level in C++, wrap it in C, and then call the C wrapper from Lua. It's extra boilerplate but damn is it nice to have a REPL for your C++ code.

Edit: Because someone else will say it - Rust binary artifacts _are_ kinda big by default. You can compile libstd from scratch on nightly (it's a couple flags) or you can amortize the cost by packing more functions into the same binary, but it is gonna have more fixed overhead than C or C++.

Re: Why Is SQLite Coded In C

#16

Post by bfkwlfkjf » Tue, Oct 14, 2025, 11:25 PM UTC

> 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.

Re: Why Is SQLite Coded In C

#17

Post by firesteelrain » Tue, Oct 14, 2025, 11:25 PM UTC

One thing I found especially interesting is the section at the end about why Rust isn’t used. It leaves open the door and at least is constructive feedback to the Rust community

Re: Why Is SQLite Coded In C

#18

Post by [deleted] » Tue, Oct 14, 2025, 11:25 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…

[deleted]

Re: Why Is SQLite Coded In C

#19

Post by DarkNova6 » Tue, Oct 14, 2025, 11:26 PM UTC

> All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include:

- Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.

- Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.

- Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.

- Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.

- Rust needs a mechanism to recover gracefully from OOM errors.

- Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

Re: Why Is SQLite Coded In C

#20

Post by dgfitz » Tue, Oct 14, 2025, 11:34 PM UTC

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.

Talking about C99, or C++11, and then “oh you need the nightly build of rust” were juxtaposed in such a way that I never felt comfortable banging out “yum install rust” and giving it a go.