Lack of multiple independent implementations means we can't ever switch to a different programing language or radically different system architecture.
Nobody is feasibly going to rewrite Sqlite in Rust.
So yeah, it is important.
Nobody is feasibly going to rewrite Sqlite in Rust.
So yeah, it is important.
> 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.
> 2. Safe programming languages solve the easy problems: memory leaks, use-after-free errors, array overruns, etc. Safe languages provide no help beyond ordinary C code in solving the rather more difficult problem of computing a correct answer to an SQL statement.
(My commentary) So SQLite development is at such a different level to normal application that the memory safety errors that are a concern for us mortals are the "easy" problems for SQLite developers!
> 5. 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.
(My commentary) I don't really agree with this one: If a branch cannot possibly be taken then I don't think it counts towards your coverage percentage... just like, if you're careful never to dereference null pointers, you don't include dereferencing null pointers as a missing part of your test coverage. Still, I thought it was very interesting, especially since it's not quite the argument I was expecting (that those checks are wasted CPU time and binary bloat because they're not needed). (Edit: What's more, exactly this situation applies with SQLite's own ALWAYS() and NEVER() macros [1])
[1] https://sqlite.org/assert.html#different_behaviors_according...
If they are at 100% today, it'd be a very convincing argument to keep it that way.
Hardening sqlite to get some security back from the insanity internally is a herculean task. I only scratched the surface with mine. Fts accepting custom tokenizers by pointer, dynamically! If someone wants a different tokenizer it needs to compiled in.
Simple selects being destructive. https://research.checkpoint.com/2019/select-code_execution-f... No security settings on by default. Dos'able. You can easily overwrite all internal and public tables. A hackers dream.
Rust would not help at all, only a proper rewrite.
It fails by calling C++ a object oriented language, which is false. C++ is a deterministic destruction language.
But in the end it doesn't matter, sqlite has been in C long enough that all the hard things C++ gives you for free have been coded manually anyway so there is no real point. For new code C++ might be better, but that is debatable. Just like rust might be better, but that is debatable.
Per (Genuine) curiosity why ? I know (good) database systems are hard to make but do sqlite have particulary 'hard' part which are near impossible to replicate ? Especially since we now have a (I assume) well documented base implementation and an extensive test suite/history of error to avoid ?
Is making à file based database that hard,compared to creating new programming language for exemple ?
Yes. I can hack together a trivial compiler in a weekend. A serious (non-optimising) compiler for a complex language is a task you could do in a few months.
If you gave me two year I'm not sure I could implement a filesystem API that correctly did something as simple as "atomically append to a file". See also Dan Luu's writing on the topic of filesystems: https://danluu.com/deconstruct-files/
This reliability comes from a very deep knowledge of OS API and all their corner cases. Creating a programming language typically involves less corner cases and the bugs in the compiler/runtime are much simple to reproduce (again, typically).
Sqlite is one of the most battle-tested pieces of software in the world. It's used "everywhere" and it's performant.
It is not the case, as some seem to believe, that rewriting software in Rust will magically eliminate all bugs and give a free speed boost compared to well-tested and optimised C.
So, yes.
It seems to be a Sqlite (compatible) implementation written in Go.