As a Rust developer (that's up to their neck in Rust projects) I'm really looking forward to a functioning sqlite clone. To the best of my knowledge, Sqlrite (https://github.com/joaoh82/rust_sqlite) was supposed to be that but it ended up diverging from sqlite. It'll make cross platform Rust builds easier.

Sqlite has been battletested for years.

I utterly fail to see the point in reimplementing it in some other language.

Innovate in databases - yes please - but "rewrite" - why?

Not being able to use battletested libraries written in plain C (e.g. sqlite) sounds like a hugh mark against rust as a systems programming language.

Is using C libraries an actual issue or just an aesthetic grumble?

Sqlite is probably the one C project I totally trust.

But, yeah, "cloning" projects is losing proposition (even more if open source). I wish a sqlite-like on rust? yeah, but not a clone, but in spirit (exist so much we can improve with rdbms!)

Maintainability? Performance? Tighter integration into Rust projects?

Also, with using SQLite's amazing test harness, it might even make sense to claim that the Rust re-implementation is of similar quality in terms of (lack of) bugs.

only some of the test harness is open source, see: https://sqlite.org/testing.html

If the rewrite is distributed over a quorum and columns are strongly-typed, I’m happy to see it.

I guess we can’t speak about battle testing in a new release from a “running in production with real user workloads” but if the test suite is properly implemented and has good coverage and exercises many cases and failure modes, it’s possible that a SQLite release is more battle tested on day zero than other software is when it’s been running for months or years. What do you think? A new version presumably still runs through validation before release.

Here's where the asymmetry of security bugs and feature bugs comes into play.

Introducing a buffer overflow in a small unused corner / edge case of the feature set allows an attacker to fully compromise the process, and it's thus a problem affecting a 100% of the users.

Introducing a behavioral bug in the same unused corner / edge case, will affect only a very small number if people (possibly none)

Freezing the software is no assurance of security either. I'll take ongoing maintenance of the quality of sqlite every time personally.

sqlite is known for its massive test coverage with 600x+ test to source ratio [0].

[0] https://www.sqlite.org/testing.html

I’m curious to understand what you’re looking to benefit from with a SQLite rust clone vs SQLite itself? Would it make writing apps easier? Or would it open up the internals of dB engines to rust developers? Or something else..? Honest question.

I think I answered your question in my comment, no? It'll make cross platform builds easier instead of the current steps needed for FFI libraries. My experience with cross platform FFI builds are slim but last time I tried it, it was painful (versus Rust handling it all with the right toolchain).

Can't be as hard as reimplementing SQLite, can it?

But reimplementing SQLite can be done by somebody else, whereas dealing with FFI must be done by me.

I feel like I must be misunderstanding you... why would the FFI be done by you? The rusqlite crate provides wrappers you can use, and there are probably other wrapper crates that I haven't looked at.

But I have to configure how it finds SQLite. Sure, SQLite specifically is fairly easy – I only need to enable the "bundled" crate feature and make sure my Clang version matches the Rust version so LTO works – but it's a little arcane to use Cargo with any non-Rust package in the dependency chain. Cargo Just Works™. Cargo with C FFI doesn't.

Thanks for the explanation!

Not the parent comment, but I believe they're referring to the cross compilation aspects which wouldn't be resolved by just using the rusqlite crate (I use rusqlite and have this issue).

the RIIR fallacy, again

> the RIIR fallacy, again

AYATAINWK?

Are You Aware That Acronym Is Not Widely Known?

I believe it's Rewrite it in Rust

Ah, there is nothing like perjorative acronyms ... they seem to be designed to shut down thinking rather than invite more of it.

Let's not forget that:

1. new programming languages bring excitement, creative destruction, and yes, lots of hobby projects that don't turn into battle-tested products. I'm ok with that.

2. rewriting is not the same as re-envisioning. See the comment above. SQLite was a starting point for inspiration, not the destination.

Also, we should not conflate an underlying technology with the hype around that technology:

a. Just because there is a lot of hype around Rust does not mean the advantages of Rust should be overlooked

b. Some highly-praised technologies deserve the praise. Yes, sometimes even the cynics are wrong.