Why Is SQLite Coded In C • Hacker News Board

Re: Why Is SQLite Coded In C

#121

Post by dathinab » Wed, Oct 15, 2025, 1:40 AM UTC

jonahx wrote: post #34

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 presuma…

no it's a (accidental) red Hering argument

sure safety checks are added but

it's ignoring that many of such checks get reliably optimized away

worse it's a bit like saying "in case of a broken invariant I prefer arbitrary potential highly problematic behavior over clean aborts (or errors) because my test tooling is inadequate"

instead of saying "we haven't found adequate test tooling" for our use case

Why inadequate? Because technically test setups can use

1. fault injection to test such branches even if normally you would never hit them

2. for many of such tests (especially array bound checks) you can pretty reliably identify them and then remove them from your test coverage statistic

idk. what the tooling of rust wrt this is in 2025, but around the rust 1.0 times you mainly had C tooling you applied to rust so you had problems like that back then.

Re: Why Is SQLite Coded In C

#122

Post by firesteelrain » Wed, Oct 15, 2025, 1:42 AM UTC

rednafi wrote: post #60

Also, Rust needs a better stdlib. A crate for every little thing is kinda nuts. One reason I enjoy Go is because of the pragmatic stdlib. On most cases, I can get away without pulling in any 3p deps. Now of course Go doesn’t work where you can’t tolerate GC pauses and need some sort of FFI. But because of the stdlib and faster compilation, Go somehow feels lighter than Rust.

Rust doesn’t really need a better stdlib as much as a broader one, since it is intentionally narrow. Go’s stdlib includes opinions like net/http and templates that Rust leaves to crates. The trade-off is Rust favors stability and portability at the core, while Go favors out-of-the-box ergonomics. Both approaches work, just for different teams.

Re: Why Is SQLite Coded In C

#123

Post by steveklabnik » Wed, Oct 15, 2025, 1:52 AM UTC

csande17 wrote: post #113

steveklabnik wrote: post #27

Earlier quoted context omitted.

1. Rust has had ten years since 1.0. It changes in backward compatible ways. For some people, they want no changes at all, so it’s important to nail down which sense is meant. 2. This has been demonstrated. 3. This one hinges on your definition of “obscure,” but the “without an operating system” bit is unambiguously demonstrated. 4. I am not an expert here, but given that you’re testing binaries, I’m not sure what is…

One question towards maturity: has any working version of the Rust compiler ever existed? By which I mean one that successfully upholds the memory-safety guarantees Rust is supposed to make, and does not have any "soundness holes" (which IIRC were historically used as a blank check / excuse to break backwards compatibility). The current version of the Rust compiler definitely doesn't -- there's known issues like http…

Every compiler has soundness bugs. They’re just programs like any other. This isn’t exclusive to Rust.

Re: Why Is SQLite Coded In C

#124

Post by steveklabnik » Wed, Oct 15, 2025, 1:55 AM UTC

ternaryoperator wrote: post #119

> Recoding SQLite in Go is unlikely since Go hates assert() Any idea what this refers to? assert is a macro in C. Is the implication that OP wants the capability of testing conditions and then turning off the tests in a production release? If so, then I think the argument is more that go hates the idea of a preprocessor. Or have I misunderstood the point being made?

https://go.dev/doc/faq#assertions

Re: Why Is SQLite Coded In C

#125

Post by Deanoumean » Wed, Oct 15, 2025, 1:56 AM UTC

dathinab wrote: post #118

It's kinda sad to read as most of their arguments might seem right at first but if put under scrutiny really fall apart. Like why defend C in 2025 when you only have to defend C in 2000 and then argue you have a old, stable, deeply tested, C code base which has no problem with anything like "commonly having memory safety issues" and is maintained by a small group of people very highly skilled in C. Like that argument…

The argument you propose only works for justifying a maintenance mode for and old codebase. If you want to take the chance to turn away new developers from complex abominations like C++ and Rust and garbage collected sloths like Java and get them to consider a comparatively simple but ubiquitous language that is C, you have to offer more.

Re: Why Is SQLite Coded In C

#126

Post by dathinab » Wed, Oct 15, 2025, 1:57 AM UTC

manwe150 wrote: post #116

cogman10 wrote: post #88

Earlier quoted context omitted.

It's a bad argument. Certainly don't get me wrong, SQLite is one of the best and most thoroughly tested libraries out there. But this was an argument to have 4 arguments. That's because 2 of the arguments break down as "Those languages didn't exist when we first wrote SQLite and we aren't going to rewrite the whole library just because a new language came around." Any language, including C, will emit or not emit inst…

If it was as completely tested as claimed, then switching to rust would be trivial. All you need to do is pass the test suite and all bugs would be gone. I can think of other reasons not to jump to rust (it is a lot of code, sqlite already works well, and test coverage is very good but also incomplete, and rust only solves a few correctness problems)—just not because of claiming sqlite is already tested enough to be…

> to rust would be trivial.

no, you still need to rewrite, re-optimize, etc. everything

it would make it much easier to be fully compatible, sure, but that doesn't make it trivial

furthermore part of it's (mostly internal) design are strongly influenced by C specific dev-UX aspects, so you wouldn't write them the same, so test for them (instead of integration tests) may not apply

which in general also means that you most likely would break some special purpose/usual user which do have "brittle" (not guaranteed) assumptions about SQLite

if you have code which very little if at all changes and has no major issues, don't rewrite it

but most of the new "external" things written around SQLite, alternative VFS impl. etc. tend to be at most partially written in C

Re: Why Is SQLite Coded In C

#127

Post by gerdesj » Wed, Oct 15, 2025, 1:58 AM UTC

steveklabnik wrote: post #107

gerdesj wrote: post #92

Earlier quoted context omitted.

"1. Rust has had ten years since 1.0. ..." Rust insists on its own package manager "rustup" and frowns on distro maintainers. When Rust is happy to just be packaged by the distro and rustup has gone away, then it will have matured to at least adolescence.

Rust has long worked with distro package maintainers, and as far as I know, Rust is packaged in every major Linux distribution. There are other worlds out there than Linux.

So why insist on rustup?

Re: Why Is SQLite Coded In C

#128

Post by AdamJacobMuller » Wed, Oct 15, 2025, 1:59 AM UTC

saalweachter wrote: post #51

I think beyond the historical reasons why C was the best choice when SQLite was being developed, or the advantages it has today, there's also just no reason to rewrite SQLite in another language . We don't have to have one implementation of a lightweight SQL database. You can go out right now and start your own implementation in Rust or C++ or Go or Lisp or whatever you like! You can even make compatible APIs for it…

One good reason is that people have written golang adapters, so that you can use sqlite databases without cgo.

I agree to what I think you're saying which is that "sqlite" has, to some degree, become so ubiquitous that it's evolved beyond a single implementation.

We, of course, have sqlite the C library but there is also sqlite the database file format and there is no reason we can't have an sqlite implementation in golang (we already do) and one in pure rust too.

I imagine that in the future that will happen (pure rust implementation) and that perhaps at some point much further in the future, that may even become the dominant implementation.

Re: Why Is SQLite Coded In C

#129

Post by psyclobe » Wed, Oct 15, 2025, 1:59 AM UTC

SQLite is a true landmark, c not withstanding it just happened to be the right tool at the right time and by now anything else is well not as interesting as what they have going on now; totally bucks the trend of throw away software.

Re: Why Is SQLite Coded In C

#130

Post by csande17 » Wed, Oct 15, 2025, 2:00 AM UTC

steveklabnik wrote: post #123

csande17 wrote: post #113

Earlier quoted context omitted.

One question towards maturity: has any working version of the Rust compiler ever existed? By which I mean one that successfully upholds the memory-safety guarantees Rust is supposed to make, and does not have any "soundness holes" (which IIRC were historically used as a blank check / excuse to break backwards compatibility). The current version of the Rust compiler definitely doesn't -- there's known issues like http…

Every compiler has soundness bugs. They’re just programs like any other. This isn’t exclusive to Rust.

In general, the way Rust blurs the line between "bugs in the compiler" and "problems with how the language is designed" seems pretty harmful and misleading. But it's also a core part of the marketing strategy, so...