Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Is SQLite Coded In C

sqlite.org

Post reply on HN
Print view View original

391–400 of 411 posts

Re: Why Is SQLite Coded In C

#391

Post by saghm »

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…

At the very least, I find this argument to be fairly reasonable:

> Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. It is unclear how this could be accomplished in the current crop of safe languages.

I don't think most Rust code written today has guardrails in the case of OOM. I don't think this disqualifies Rust for most things, because I happen to find the trade-off worth it compared to the things it does protect against that C doesn't, but I don't think it's a particularly controversial take that Rust still could use some ergonomic improvements around handling allocation failures. Right now, trying to create a Box or Vec can theoretically fail at runtime if no memory is available, and those failures aren't returned from the functions called to create them. Handling panics is something you can normally do in Rust, but if you're already OOM, things get complicated pretty fast.

I agree that in the long run it would probably make sense to have something like this in Rust when eventually the current maintainers aren't around, but I also don't think it makes much sense to criticize them for continuing to maintain the code that already exists.

Re: Why Is SQLite Coded In C

#392

Post by saghm »

oguz-ismail wrote: post #180
dathinab wrote: post #155

Earlier quoted context omitted.

> Had SQLite ever had a memory leak or use-after-delete bug on a production release? sure, it's an old library they had pretty much anything (not because they don't know what they are doing but because shit happens) lets check CVEs of the last few years: - CVE-2025-29088 type confusion - CVE-2025-29087 out of bounds write - CVE-2025-7458 integer overflow, possible in optimized rust but test builds check for it - CVE-…

> How is anyone still arguing for C for new projects? It just works

If your definition of "works" includes out of bounds memory access, use after free, etc., then yes. If your definition does not include those, then it demonstrably does not.

Alternately, maybe there's a spectrum of undesirable behaviors, some of which are preventable by choice of language, some of which aren't, and trying to reduce a complex set of tradeoffs to a simple binary of whether it "just works" only restates the conclusion someone has already come to because you need to actually reason about those tradeoffs to come to an informed decision of where to implicitly draw the line in the first place.

Re: Why Is SQLite Coded In C

#393

Post by saghm »

uecker wrote: post #206
krior wrote: post #192

Earlier quoted context omitted.

That list alone sounds like it does not work.

As long as it is possible to produce a OOB in something as simple as a matrix transpose, Rust also does not work: https://rustsec.org/advisories/RUSTSEC-2023-0080.html .

And something as simple as a for loop to iterate over an array of elements with an off-by-one error can cause undefined behavior in C. Let's not pretend that there's some universally-agreed-upon hierarchy of what types of bugs are unconscionable and which ones are unfortunate unavoidable facts of life just because certain ones existed in the older language and others didn't.

Re: Why Is SQLite Coded In C

#394

Post by saghm »

blibble wrote: post #255
slashdev wrote: post #109

Earlier quoted context omitted.

> They just use the name for promotional/aspirational purposes. Which feels incredibly icky. The aim is to be compatible with sqlite, and a drop-in replacement for it, so I think it's fair use. > Also, this is a VC backed project. Everyone has to eat, but I suspect that Turso will not go out of its way to offer a Public Domain offering or 50 year support in the way that SQLite has. It's MIT license open-source. And u…

> The aim is to be compatible with sqlite, and a drop-in replacement for it, so I think it's fair use. try marketing your burger company as "The Next Evolution of McDonalds" and see what happens

This might be a compelling argument if McDonalds were the name of a public domain project rather than a trademarked corporation

Re: Why Is SQLite Coded In C

#395

Post by matinsjoe54 »

saghm wrote: post #394
blibble wrote: post #255

Earlier quoted context omitted.

> The aim is to be compatible with sqlite, and a drop-in replacement for it, so I think it's fair use. try marketing your burger company as "The Next Evolution of McDonalds" and see what happens

This might be a compelling argument if McDonalds were the name of a public domain project rather than a trademarked corporation

[dead]

Re: Why Is SQLite Coded In C

#396

Post by QuiEgo »

aw1621107 wrote: post #145
QuiEgo wrote: post #112

Earlier quoted context omitted.

> 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. I’d love to see rust be so stable that MSRV is an anachronism. I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable.

> I want it to be unthinkable you wouldn’t have any reason not to support Rust from forever ago because the feature set is so stable. What other languages satisfy this criteria?

This is extremely common in the embedded and systems programming space, which Rust is otherwise attractive to use in.

For example, a very popular library in the systems/embedded space, cjson, works with C89. FreeRTOS works with C99. This is a very common pattern in major libraries. It is very rare that taking a dependency could force you to update your toolchain in the embedded space.

Toolchain updates invalidate your entire testing history and make you revalidate everything, which is often a giant PITA when your testing involves physical things (ex you may have to plug and unplug things, put the system in chambers that replicate certain environmental conditions, etc).

Re: Why Is SQLite Coded In C

#398

Post by saghm »

uecker wrote: post #213
bsder wrote: post #204

Earlier quoted context omitted.

> 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. If I want a "C Library", I want a "C Library" and not some weird abomination that has been surgically grafted to libstdc++ or similar (but be careful of which version as they're not compatible and the name mangling changes and ...). This isn't theoretical…

Rust libraries also impose an - in my opinion - unacceptable burden to the open source ecosystem: https://www.debian.org/releases/trixie/release-notes/issues.... This makes me less safe rather than more. Note that there is a substantial double standard here, we could never in the name of safety impose this level of burden from C tooling side because maintainers would rightfully be very upset (even toggling a warning…

The link you provided seems light on details. From what I can tell, it sounds like Debian tooling has trouble with packages that are statically linked? It's not clear to me how I'm expected to weigh that against something like memory safety, especially without any more context around how much of this is specific to the tooling Debian uses rather than something inherent to static linking as a whole. Without that, it seems just as reasonable to argue against using Debian until they improve their tooling.

Re: Why Is SQLite Coded In C

#399

Post by saghm »

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…

The latter two of these points seem pretty subjective. I feel like they're written in a way that anyone could easily make an argument for or against Rust having fulfilled them today or literally at any point in the future. There's not really any way to refute an argument that something is "changing too fast", "not boring enough", or "hasn't demonstrated it can do the kind of work C does". I'd find them more compelling if they were expressed in a way it was actually possible to verify whether Rust reaches them or not at some arbitrary point in the future. Otherwise, people will inevitably just see them as a reflection of their existing opinion on whether it's wise or foolish for SQLite to use C rather than Rust.

Re: Why Is SQLite Coded In C

#400

Post by masfoobar »

jasonthorsness wrote: post #21

“None of the safe programming languages existed for the first 10 years of SQLite's existence. SQLite could be recoded in Go or Rust, but doing so would probably introduce far more bugs than would be fixed, and it may also result in slower code.” Modern languages might do more than C to prevent programmers from writing buggy code, but if you already have bug-free code due to massive time, attention, and testing, and t…

Seems we live in a "cool" or "flashy" era or rewriting everything in Rust.

Dont get me wrong, despite not taking time to learn Rust at this time, I am aware that memory safety is the thing at this time. Yes... some software might do better being rewritten from C to Rust. However, there are other projects that have been worked on for years and years. Sqlite is an example of this. That quote above is 100%

Various GNU tools are being replaced. Dont just expect them to be 100% despite being "memory safe" -- they will have to fo through various tweaks to boost performance. With Rust likely (still) to go through some further changes, I am sure Linus will get frustrated at some points within the Linux Kernel. We shall see.

Point is - some things are just better left with their mature state. Though.. on the flip side, we are have to think about the younger generation. Will SQlite survive if it continues to use C? It's likely to be a language that each new generation will not bother, and focus on Rust, Zig.. or whatever comes out in the future.

I am just waiting for rewrite of Doom or Quake (I am sure they already exist if I can be bothered to search.. in Rust)

Post reply on HN