>Our goal is to build a reimplementation of SQLite from scratch, fully compatible at the language and file format level, with the same or higher reliability SQLite is known for, but with full memory safety and on a new, modern architecture.
And they call it rewrite in a recent followup post[1].
The wording & framing of these things is an interesting topic in the context of the W3C's decision to drop WebSQL.
A "rewrite" softly implies a replacement (intent that SQLite users would all migrate to Turso eventually & SQLite would cease to exist as a project). This isn't the strict definition of a rewrite but the implication is there in the language.
OTOH the W3C shut down that spec because it required competing implementations to exist. This imagines a world where Turso & SQLite coexist actively.
E.g. micropython isn't a rewrite of cpython even though they both target compatible python, Chrome isn't a rewrite of Firefox even though they both target a range of compatible languages & formats (but Firefox was a rewrite of Netscape - the word depends heavily on context).
I realise this usage isn't coming from you, it's coming from the Turso devs themselves, but it does feel like an overstep on their part.
The Turso guys can use whatever words they like in their blogposts, they're not the authority on whether it constitutes a rewrite.
It's the Rust superiority complex that's subtly speaking thru the Rust "rewrite" projects. Of course rust is better so why would anyone want to stay on the old, C-coded version?
They may call it all they want. It's been common between some Rust developers to steal valor by highjacking the name of original project for their own fun rewrites.
Turso a third party project that has nothing to do with SQLite.
Ah, it was about the usage of rewrite by such third-party efforts. In this case, yes, the original reimplementation (could have also call it alternative) wording is probably better. Was confused at the "happens to have some compatibility" part because the project was started with that intent so it wasn't a coincidence.
It's not a reimplementation either. It's just a separate project which has nothing to do with SQLite. Thus mentioning it as "SQLite resomething" is not fair.
SQLite compatibility at file level is a nice perk which I am not totally convinced is truly needed at all. Like, it's hard to imagine scenarios where this is useful. But it can be.
"...hard to imagine scenarios where [file-level compatibility] is useful" what am I missing? Surely dropping a more performant dbm into an existing project would be the application? No?
[1] https://github.com/tursodatabase/turso