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

131–140 of 411 posts

Re: Why Is SQLite Coded In C

#131

Post by dangus »

Deanoumean wrote: post #125
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.

Is SQLite looking for new developers? Will they ever need a large amount of developers like a mega-corp that needs to hire 100 React engineers?

Re: Why Is SQLite Coded In C

#132

Post by Deanoumean »

Aurornis wrote: post #62
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.

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.

You didn't understand the argument. The testing is what instills the confidence.

Re: Why Is SQLite Coded In C

#133

Post by tonyhart7 »

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.

me when I dont know ball:

Re: Why Is SQLite Coded In C

#134

Post by cmrx64 »

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…

(it’s from 2017)

Re: Why Is SQLite Coded In C

#135

Post by dathinab »

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…

> 2.

ironically if we look at how things play out in practice rust is far more suited as general purpose languages then C, to a point where I would argue C is only a general purpose language on technicality not on practical IRL basis

this is especially ridiculous when they argue C is the fasted general purpose language when that has proven to simply not hold up to larger IRL projects (i.e. not micro benchmarks)

C has terrible UX for generic code re-use and memory management, this often means that in IRL projects people don't write the fasted code. Wrt. memory management it's not rare to see unnecessary clones, as not doing so it to easy to lead to bugs. Wrt. data structures you write the code which is maintainable, robust and fast enough and sometimes add the 10th maximal simple reimplementation (or C macro or similar) of some data structure instead of using reusing some data structures people spend years of fine tuning.

When people switched a lot from C to C++ most general purpose projects got faster, not slower. And even for the C++ to Rust case it's not rare that companies end up with faster projects after the switch.

Both C++ and Rust also allow more optimization in general.

So C is only fastest in micro benchmarks after excluding stuff like fortran for not being general purpose while itself not really being used much anymore for general purpose projects...

Re: Why Is SQLite Coded In C

#136

Post by nubbler »

thayne wrote: post #102
binary132 wrote: post #68

Earlier quoted context omitted.

I think it’s less like doubting that the given panic works and more like an extremely thorough proof that all possible branches of the control flow have acceptable behavior. If you haven’t tested a given control flow, the issue is that it’s possible that the end result is some indeterminate or invalid state for the whole program, not that the given bounds check doesn’t panic the way it’s supposed to. On embedded for…

But does it matter if that control flow is unreachable? If the check never fails, it is logically equivalent to not having the check. If the code isn't "correct" and the panic is reached, then the equivalent c code would have undefined behavior, which can be much worse than a panic.

In the first case, if it is actually unreachable, I would never want that code ending up in my binary at all. It must be optimised out.

Your second case implies that it is reachable.

Re: Why Is SQLite Coded In C

#137

Post by dathinab »

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…

has there ever been a modern optimizing C compiler free of pretty serious bugs? (it's a rhetoric question, there hasn't been any)

Re: Why Is SQLite Coded In C

#138

Post by nubbler »

NobodyNada wrote: post #90
jonahx wrote: post #34

Earlier quoted context omitted.

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…

> But (if I understand correctly) these are checks implicitly added by the compiler. This is a dubious statement. In Rust, the array indexing operator arr[i] is syntactic sugar for calling the function arr.index(i), and the implementation of this function on the standard library's array types is documented to perform a bounds-check assertion and access the element. So the checks aren't really implicitly added -- you…

Another commenter in this thread used the phrase "complex abomination" which seems more and more apt the more I learn about Rust.

Re: Why Is SQLite Coded In C

#139

Post by [deleted] »

cmrx64 wrote: post #134
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…

(it’s from 2017)

[deleted]

Re: Why Is SQLite Coded In C

#140

Post by evil-olive »

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.

> maybe I could see it on a space shuttle?

"Airbus confirms that SQLite is being used in the flight software for the A350 XWB family of aircraft."

https://www.sqlite.org/famous.html

Post reply on HN