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

171–180 of 411 posts

Re: Why Is SQLite Coded In C

#171

Post by Aurornis »

estebank wrote: post #87
Aurornis wrote: post #62

Earlier quoted context omitted.

I guess I don’t find that argument very compelling. If you’re convinced the code branch can’t ever be taken, you also should be confident that it doesn’t need to be tested. This feels like chasing arbitrary 100% test coverage at the expense of safety. The code quality isn’t actually improved by omitting the checks even though it makes testing coverage go up.

In safety critical spaces you need to be able to trace any piece of a binary back to code back to requirements. If a piece of running code is implicit in code, it makes that traceability back to requirements harder. But I'd be surprised if things like bounds checks are really a problem for that kind of analysis.

I don’t see the issue. The operations which produce a bounds check are traceable back to the code which indexes into something.

Re: Why Is SQLite Coded In C

#172

Post by aw1621107 »

csande17 wrote: post #154
steveklabnik wrote: post #144

Earlier quoted context omitted.

What makes you say this is a core part of the marketing strategy? I don’t think Rust’s marketing has ever focused on compiler bugs or their absence.

You are correct that Rust's marketing does not claim that there are no bugs in its compiler. In fact it does the opposite: it suggests that there are no problems with the language , by asserting that any observed issue in the language is actually a bug in the compiler. Like, in the C world, there's a difference between "the C specification has problems" and "GCC incorrectly implements the C specification". You can ma…

> And even if there's some fundamental issue with how traits work that hasn't been resolved for six years, that can get brushed off as merely a compiler bug.

Is it getting brushed off as merely a compiler bug? At least if I'm thinking of the same bug as you [0] the discussion there seems to be more along the lines of the devs treating it as a "proper" language issue, not a compiler bug. At least as far as I can tell there hasn't been a resolution to the design issue, let alone any work towards implementing a fix in the compiler.

The soundness issue that I see more frequently get "brushed off as merely a compiler bug" is the lifetime variance one underpinning cve-rs [1], which IIRC the devs have long decided what the proper behavior should be but actually implementing said behavior is blocked behind some major compiler reworks.

> has made a lot of backwards-incompatible changes

Not sure I've seen much evidence for "a lot" of compatibility breaks outside of the edition system. Perhaps I'm just particularly (un)lucky?

> because there is no such thing as a design issue in "the Rust language"

I'm not sure any of the Rust devs would agree? Have any of them made a claim along those lines?

[0]: https://github.com/rust-lang/rust/issues/57893

[1]: https://github.com/Speykious/cve-rs

Re: Why Is SQLite Coded In C

#173

Post by tomjakubowski »

hypeatei wrote: post #83
oconnor663 wrote: post #64

Earlier quoted context omitted.

Yes. You have to write `unsafe { ... }` around it, so there's an ergonomic penalty plus a more nebulous "sense that you're doing something dangerous that might get some skeptical looks in code review" penalty, but the resulting assembly will be the same as indexing in C.

I figured, but I guess I don't understand this argument then. SQLite as a project already spends a lot of time on quality so doing some `unsafe` blocks with a `// SAFETY:` comment doesn't seem unreasonable if they want to avoid the compiler inserting a panic branch for bounds checks.

In many cases LLVM can prove the bounds check is redundant or otherwise is unnecessary and will optimize it away.

Re: Why Is SQLite Coded In C

#174

Post by BrouteMinou »

hoppp wrote: post #164
steveklabnik wrote: post #160

Earlier quoted context omitted.

You control the dependencies you put in Cargo.toml.

What about the dependencies of your dependencies? I don't put too many things in Cargo.toml and it still pulls like a hundred things

Your system is going to be owned, but at least, it's going to be "memory safely" owned!

P. S.

I you don't account all the unsafe sections scattered everywhere in all those dependencies.

Re: Why Is SQLite Coded In C

#175

Post by tomjakubowski »

wodenokoto wrote: post #23

I think it’s more interesting that DuckDB is written in C++ and not rust than SQLite. SQLite is old, huge and known for its gigantic test coverage. There’s just so much to rewrite. DuckDB is from 2019, so new enough to jump on the “rust is safe and fast”

If I'm remembering a DuckDB talk I attended correctly, they chose C++ because they were most confident in their ability to write clear code in it which would be autovectorized by the compilers they were familiar with. Rust in 2019 didn't have a clear high level SIMD story yet and the developers (wisely) did not want to maintain handrolled SIMD code.

Re: Why Is SQLite Coded In C

#176

Post by drnick1 »

steveklabnik wrote: post #27
DarkNova6 wrote: post #19

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

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…

I think Rust (and C++) are just too complicated and visually ugly, and ultimately that hurts the maintainability of the code. C is simple, universal, and arguably beautiful to look at.

Re: Why Is SQLite Coded In C

#177

Post by pklausler »

aw1621107 wrote: post #165
hoppp wrote: post #159

Earlier quoted context omitted.

Fortran, cobol, C or other old languages that stopped changing but are still used.

All three of the languages you list are still actively updated. Coincidentally, the latest standard for all three of them is from 2023(ish): - C23: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf - Cobol 2023: https://www.incits.org/news-events/news-coverage/available-n... (random press release since a PDF of the standard didn't immediately show up in a search) - Fortran 2023: https://wg5-fortran.org/N2201…

Can’t compile with just a PDF file, though.

Re: Why Is SQLite Coded In C

#178

Post by mamcx »

hoppp wrote: post #158
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…

Rust has dependency hell and supply chain attacks like with npm.

But is optional. For this kind of project, is logical to adopt something like the tiger battle ethos and own all the code and have no external deps (or vendor them). Even do your own std if wanna.

Is hard work? But is not that different from what you see in certain C projects that neither use external deps

Re: Why Is SQLite Coded In C

#179

Post by aw1621107 »

array_key_first wrote: post #162
metaltyphoon wrote: post #30

Earlier quoted context omitted.

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

> More control over what exactly? Allocations? There is nothing Zig can do that Rust can’t. I mean yeah, allocations. Allocations are always explicit. Which is not true in C++ or Rust. Personally I don't think it's that big of a deal, but it's a thing and maybe some people care enough.

> Which is not true in [] Rust.

...If you're using the alloc/std crates (which to be fair, is probably the vast majority of Rust devs). libcore and the Rust language itself do not allocate at all, so if you use appropriate crates and/or build on top of libcore yourself you too can have an explicit-allocation Rust (though perhaps not as ergonomic as Zig makes it).

Re: Why Is SQLite Coded In C

#180

Post by oguz-ismail »

dathinab wrote: post #155
daxfohl wrote: post #93

It sounds like the core doesn't even allocate, and presumably the extended library allocates in limited places using safe patterns. So there wouldn't be much benefit from Rust anyway, I'd think. Had SQLite ever had a memory leak or use-after-delete bug on a production release? If so, that answers the question. But I've never heard of one. Also, does it use doubly linked lists or graphs at all? Those can, in a way, be…

> 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

Post reply on HN