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

261–270 of 411 posts

Re: Why Is SQLite Coded In C

#261

Post by skywhopper »

refulgentis wrote: post #95
estebank wrote: post #87

Earlier quoted context omitted.

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.

Yeah sounds too clever by half, memory safe languages are less safe because they have bounds checks...maybe I could see it on a space shuttle? Well, only in the most CYA scenarios, I'd imagine.

SQLite is used in a lot of hypercritical application areas. I’d almost be surprised if it’s not part of some if not all modern spaceflight stacks.

Re: Why Is SQLite Coded In C

#262

Post by actionfromafar »

Hendrikto wrote: post #260
devjab wrote: post #241

Earlier quoted context omitted.

I quite like that Zig works a drop in for C in a few use cases. It's been very nice to utilize it along with our Python and regular C binaries. We attempted to move into Go because we really like the philosophy and opinions it force upon it's developers, but similar to interpreted languages it can be rather hard to optimize it. I'm sure people more talented than us would have an easy time with it, but they don't work…

> We attempted to move into Go […], but similar to interpreted languages it can be rather hard to optimize it. […] So it was easier to just go with Python I don’t get that. You had trouble optimizing Go, so you went with Python?

Python + C. Probably C for the optimized parts.

Re: Why Is SQLite Coded In C

#263

Post by skywhopper »

timv wrote: post #169
nimih wrote: post #147

Earlier quoted context omitted.

> 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. I don't think I would (personally) ever be comfortable asserting that a code branch in the machine instructions emitted by a compiler can't ever be taken, no matter what, with 100% confidence, during a large fraction of situations in realistic application or library development, as to do so would…

The argument here is that they're confident that the bounds check isn't needed, and would prefer the compiler not insert one. The choices therefore are: 1. No bound check 2. Bounds check inserted, but that branch isn't covered by tests 3. Bounds check inserted, and that branch is covered by tests I'm skeptical of the claim that if (3) is infeasible then the next best option is (1) Because if it is indeed an impossibl…

I think you’re misreading their statement. They aren’t saying they don’t want the compiler to insert the additional code. They’re saying they want to test all code the compiler generates.

Re: Why Is SQLite Coded In C

#264

Post by skywhopper »

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…

I assume they have written this extensive document with lots of details in response to two and a half decades of thousands of “why not rewrite in X?” questions they’ve had to endure.

Re: Why Is SQLite Coded In C

#265

Post by [deleted] »

scuff3d wrote: post #191
mungaihaha wrote: post #170

Earlier quoted context omitted.

> But most of the other arguments they list can be picked apart and are only half true I'd like to see you pick the other arguments apart

> Other programming languages sometimes claim to be "as fast as C". But no other language claims to be faster than C for general-purpose programming, because none are. Not OP, And I'm not really arguing with the post, but this struck me as a really odd thing to include in the article. Of course nothing is going to be faster then C, because it compiles straight to machine code with no garbage collection. Literally any…

[deleted]

Re: Why Is SQLite Coded In C

#266

Post by cogman10 »

Ferret7446 wrote: post #148
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…

> Any language, including C, will emit or not emit instructions that are "invisible" to the author Presumably this is why they do 100% test coverage. All of those instructions would be tested and not invisible to the test suite

How could they know? Any changes to the compiler will potentially generate new code.

A new compiler, new flags, a new version. These all can create new invisible untested branches.

Re: Why Is SQLite Coded In C

#267

Post by csande17 »

aw1621107 wrote: post #240
csande17 wrote: post #224

Earlier quoted context omitted.

Oh, I didn't realize steveklabnik wasn't an official member of the project anymore (as of 2022 apparently: https://blog.rust-lang.org/2022/01/31/changes-in-the-core-te... ). I do think he still expressed this position back when he was a major public face of the language, but it seems unfair to single him out and dig through his comment history. Rust's marketing is pretty grassroots in general, but even current offici…

Yeah, Steve has been "just" a well-informed third party for a while now. I would be curious if he has commented on that specific issue before; usually when unsoundness comes up it's cve-rs which is mentioned. > but even current official sources like https://rust-lang.org/ say things like "Rust’s rich type system and ownership model guarantee memory-safety" that are only true of the vague-ideal "Rust language" and are…

I agree that it's a tough situation. "The type system guarantees memory safety" is an extremely important pillar of Rust's identity. They kind of have to portray all soundness issues as "more compiler bugs than something broken in the language itself" (see eg https://news.ycombinator.com/item?id=21930599 which references a GitHub label that AIUI would've included the trait coherence thing at the time) to keep making that claim. It is a core part of the marketing strategy.

Re: Why Is SQLite Coded In C

#268

Post by yomismoaqui »

biohazard2 wrote: post #253
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…

> there's also just no reason to rewrite SQLite in another language. […] But why would we want to throw away the perfectly good C implementation, and why would we expect the C experts who have been carefully maintaining SQLite for a quarter century to be the ones to learn a new language and start over? The SQLite developers are actually open to the idea of rewriting SQLite in Rust, so they must see an advantage to it…

My theory is they wrote this just to get the ‘rewrite everything in Rust’ crowd off their backs.

Re: Why Is SQLite Coded In C

#269

Post by rirze »

yomismoaqui wrote: post #268
biohazard2 wrote: post #253

Earlier quoted context omitted.

> there's also just no reason to rewrite SQLite in another language. […] But why would we want to throw away the perfectly good C implementation, and why would we expect the C experts who have been carefully maintaining SQLite for a quarter century to be the ones to learn a new language and start over? The SQLite developers are actually open to the idea of rewriting SQLite in Rust, so they must see an advantage to it…

My theory is they wrote this just to get the ‘rewrite everything in Rust’ crowd off their backs.

I think it’s the opposite. They want to atleast explore rewriting in Rust but are afraid of backlash. Hence why they’re open to private discussion. I can imagine they are split internally.

Re: Why Is SQLite Coded In C

#270

Post by esterna »

Ekaros wrote: post #198
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.

If a code branch can't be ever taken. Doesn't that mean you do not need it? Basically it must be code that will not get executed. So leaving it out does not matter. If you then can come up a scenario where you need it. Well in fully tested code you do need to test it.

[dead]
Post reply on HN