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

41–50 of 411 posts

Re: Why Is SQLite Coded In C

#41

Post by casparvitch »

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?

Re: Why Is SQLite Coded In C

#42

Post by simonw »

zvmaz wrote: post #33
slashdev wrote: post #31

This is ignoring the elephant in the room: SQLite is being rewritten in Rust and it's going quite well. https://github.com/tursodatabase/turso It has async I/O support on Linux with io_uring, vector support, BEGIN CONCURRENT for improved write throughput using multi-version concurrency control (MVCC), Encryption at rest, incremental computation using DBSP for incremental view maintenance and query subscriptions. Time…

In the link you provided, this is what I read: "An in-process SQL database, compatible with SQLite." Compatible with SQLite. So it's another database?

Yeah, I don't think it even counts as a fork - it's a ground-up re-implementation which is already adding features that go beyond the original.

Re: Why Is SQLite Coded In C

#44

Post by jandrewrogers »

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.

Re: Why Is SQLite Coded In C

#45

Post by metaltyphoon »

Cloudef wrote: post #36
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.

I think zig generally composes better than rust. With rust you pretty much have to start over if you want reusable / composable code, that is not use the default std. Rust has small crates for every little thing because it doesn't compose well, as well to improve compile times. libc in the default std also is major L.

> I think zig generally composes better than rust.

I read your response 3 times and I truly don't know what you mean. Mind explaining with a simple example?

Re: Why Is SQLite Coded In C

#46

Post by oconnor663 »

jonahx wrote: post #34
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.

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…

> questioning the correctness of this auto-generated code

I wouldn't put it that way. Usually when we say the compiler is "incorrect", we mean that it's generating code that breaks the observable behavior of some program. In that sense, adding extra checks that can't actually fail isn't a correctness issue; it's just an efficiency issue. I'd usually say the compiler is being "conservative" or "defensive". However, the "100% branch testing" strategy that we're talking about makes this more complicated, because this branch-that's-never-taken actually is observable, not to the program itself but to its test suite.

Re: Why Is SQLite Coded In C

#47

Post by assimpleaspossi »

slashdev wrote: post #31

This is ignoring the elephant in the room: SQLite is being rewritten in Rust and it's going quite well. https://github.com/tursodatabase/turso It has async I/O support on Linux with io_uring, vector support, BEGIN CONCURRENT for improved write throughput using multi-version concurrency control (MVCC), Encryption at rest, incremental computation using DBSP for incremental view maintenance and query subscriptions. Time…

>>SQLite is being rewritten in Rust

SQLite is NOT being rewritten in Rust!

>>Turso Database is an in-process SQL database written in Rust, compatible with SQLite.

Re: Why Is SQLite Coded In C

#48

Post by hypeatei »

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.

Couldn't a method like `get_unchecked()` be used to avoid the bounds check[0] if you know it's safe?

0: https://doc.rust-lang.org/std/vec/struct.Vec.html#method.get...

Re: Why Is SQLite Coded In C

#50

Post by lionkor »

jonahx wrote: post #34
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.

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…

It's not like that, the compiler explicitly doesn't do compile-time checks here and offloads those to the runtime.

Rust does not stop you from writing code that accesses out of bounds, at all. It just makes sure that there's an if that checks.

Post reply on HN