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

161–170 of 411 posts

Re: Why Is SQLite Coded In C

#161

Post by wodenokoto »

jandrewrogers wrote: post #44
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 maximum performance is a top objective, it is probably because C++ produces faster binaries with less code. Modern C++ specifically also has a lot of nice compile-time safety features, especially for database-like code.

I can’t verify those claims one way or another, but I’m interested to hear why they were downvoted.

Re: Why Is SQLite Coded In C

#162

Post by array_key_first »

metaltyphoon wrote: post #30
plainOldText wrote: post #4

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.

> 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.

Re: Why Is SQLite Coded In C

#163

Post by unsungNovelty »

As I write more code, use more software and read about rewrites...

The biggest gripe I have with a rewrite is... A lof of the time we rewrite for feature parity. Not the exact same thing. So you are kind ignoring/missing/forgetting all those edge cases and patches that were added along the way for so many niche or otherwise reasons.

This means broken software. Something which used to work before but not anymore. They'll have to encounter all of them again in the wild and fix it again.

Obviously if we are to rewrite an important piece of software like this, you'd emphasise more on all of these. But it's hard for me to comprehend whether it will be 100%.

But other than sqlite, think SDL. If it is to be rewritten. It's really hard for me to comprehend that it's negligible in effect. Am guessing horrible releases before it gets better. Users complaining for things that used work.

C is going to be there long after the next Rust is where my money is. And even if Rust is still present, there would be a new Rust then.

So why rewrite? Rewrites shouldn't be the default thinking no?

Re: Why Is SQLite Coded In C

#164

Post by hoppp »

steveklabnik wrote: post #160
hoppp wrote: post #158

Earlier quoted context omitted.

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

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

Re: Why Is SQLite Coded In C

#165

Post by aw1621107 »

hoppp wrote: post #159
aw1621107 wrote: post #145

Earlier quoted context omitted.

> 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?

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-N2250/N2212.pdf

C2Y has a fair number of already-accepted features as well and it's relatively early in the standard release cycle: https://thephd.dev/c2y-hitting-the-ground-running

Re: Why Is SQLite Coded In C

#166

Post by Jtsummers »

casparvitch wrote: post #41
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…

Why can't `if condition { panic(err) }' be used in go as an assert equivalent?

Because C's assert gets compiled out if you have NDEBUG defined in your program. How do you do conditional compilation in Go (at the level of conditionally including or not including a statement)?

Re: Why Is SQLite Coded In C

#167

Post by OptionOfT »

vlovich123 wrote: post #153
btilly wrote: post #91

Earlier quoted context omitted.

One of the things that SQLite is explicitly designed to do is have predictable behavior in a lot of conditions that shouldn't happen. One of those predictable behavior is that it does its best to stay up and running, and continuing to do the best it can. Conditions where it should succeed in doing this include OOM, the possibility of corrupted data files, and (if possible) misbehaving CPUs. Automatic array bounds che…

In rust at least you are free to access an array via .get which returns an option and avoids the “compiler inserted branch” (which isn’t compiler inserted by the way - [] access just implicitly calls unwrap on .get and sometimes the compiler isn’t able to elide). Also you rarely need to actually access by index - you could just access using functional methods on .iter() which avoids the bounds check problem in the fi…

For slices the access is handled inside of the compiler: https://github.com/rust-lang/rust/blob/235a4c083eb2a2bfe8779...

I'm checking to see how array access is implemented, whether through deref to slice, or otherwise.

Re: Why Is SQLite Coded In C

#168

Post by vlovich123 »

OptionOfT wrote: post #167
vlovich123 wrote: post #153

Earlier quoted context omitted.

In rust at least you are free to access an array via .get which returns an option and avoids the “compiler inserted branch” (which isn’t compiler inserted by the way - [] access just implicitly calls unwrap on .get and sometimes the compiler isn’t able to elide). Also you rarely need to actually access by index - you could just access using functional methods on .iter() which avoids the bounds check problem in the fi…

For slices the access is handled inside of the compiler: https://github.com/rust-lang/rust/blob/235a4c083eb2a2bfe8779... I'm checking to see how array access is implemented, whether through deref to slice, or otherwise.

I had Vec in mind but regardless nothing forces you to use the bounds-checked variant vs one that returns option. And if you really are sure the bounds hold you can always use the assume crate or just unwrap_unchecked explicitly.

Re: Why Is SQLite Coded In C

#169

Post by timv »

nimih wrote: post #147
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 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 impossible scenario, then the lack of coverage shouldn't matter. If it's not an impossible scenario then you have an untested case with option (1) - you've overrun the bounds of an array, which may not be a branch in the code but is definitely a different behaviour than the one you tested.

Re: Why Is SQLite Coded In C

#170

Post by mungaihaha »

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…

> 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

Post reply on HN