[HN Gopher] Why Is SQLite Coded in C and not Rust
___________________________________________________________________
Why Is SQLite Coded in C and not Rust
Author : plainOldText
Score : 12 points
Date : 2025-10-14 20:32 UTC (2 hours ago)
(HTM) web link (www.sqlite.org)
(TXT) w3m dump (www.sqlite.org)
| mikece wrote:
| 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 this library but if we do it
| will be in C (I did managed to get the "wrap it for each
| language" proposal pre-approved).
| plainOldText wrote:
| 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.
| Jtsummers wrote:
| > Nearly all systems have the ability to call libraries written
| in C. This is not true of other implementation languages.
|
| From section "1.2 Compatibility". How easy is it to embed a
| library written in Zig in, say, a small embedded system where
| you may not be using Zig for the rest of the work?
|
| Also, since you're the submitter, why did you change the title?
| It's just "Why is SQLite Coded in C", you added the "and not
| Rust" part.
| plainOldText wrote:
| The article allocates the last section to explaining why Rust
| is not a good fit (yet) so I wanted the title to cover that
| part of the conversation since I believe it is meaningful. It
| illustrates the tradeoffs in software engineering.
| Jtsummers wrote:
| > Otherwise please use the original title, unless it is
| misleading or linkbait; don't editorialize.
|
| From the site guidelines:
| https://news.ycombinator.com/newsguidelines.html
| pm2222 wrote:
| 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 needs to demonstrate that it can do the kinds of work that C
| does in SQLite without a significant speed penalty.
| rstuart4133 wrote:
| > 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 unreachable!() for such situations, and you would hope
| that: if array_access_out_of_bounds {
| unreachable!(); }
|
| is recognised by the Rust tooling and just ignored. That's
| effectively the same as SQLite is doing now by not doing the
| check. But it isn't ignored by the tooling: unreachable!() is
| reported as a missed line. Then there is the test code coverage
| including the standard output by default, and you have to use
| regex's on path names to remove it.
| Jtsummers wrote:
| Two previous, and substantial, discussions on this page:
|
| https://news.ycombinator.com/item?id=28278859 - August 2021
|
| https://news.ycombinator.com/item?id=16585120 - March 2018
___________________________________________________________________
(page generated 2025-10-14 23:01 UTC)