2017 at least[1] but "This page was last updated on 2025-05-09 15:56:17Z." [1] https://web.archive.org/web/20170701061906/https://sqlite.or...
I'd like to see Steve Yegge unleash his Gas Town with a convoy or whatever it's called to rewrite the sqlite in Rust obviously preserving 100% test coverage. Results are a guaranteed bombshell regardless of whether it succeeds or fails.
What’s Steve Yegge got to do with Rust? And who’s gonna sponsor some 10,000 hours to “rewrite the sqlite in Rust obviously preserving 100% test coverage”? Will he do it just for the memes, or did you think Rust is so cool there is no effort involved?
> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language. But I don't see Rust ever goin…
Uh oh! I think Rust may settle down eventually. Who knows, maybe one of the devs will chime in.
> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language. But I don't see Rust ever goin…
The 'some degree' is pretty important, though. The Rust language undergoes backwards incompatible changes sometimes, but the Rust tools do not. The 2024 edition has breaking changes since the 2021 edition, but all compilers can compile all historical editions and will do so forever, and new language features are available in as many editions as possible, and editions can be mixed in a dependency tree, so you do not ever have to update your 2015 edition code for anything.
Yup. But, they're all good in their own way. They're just a means to an end. If the end result is good, reliable, maintainable: whatever you use is good.
The bit about why not OOP seems a bit old. I think we're past a point where people are going for OOP as the default shape of code. Overall, it makes sense. C is a systems language, and a DB is a system abstraction. You shouldn't need to build a deep hierarchy of abstractions on top of C, just stick with the lego blocks you have. If the project had started in 2016, maybe they would have gone for c++, which is a differ…
I think they would have still gone with C. I still do.
Zig hasn't even had it's first release yet. And projects written in it still break in new releases. Given their stance on boringness and maturity it would make no sense for Sqlite to consider zig yet.
SQLite is never gonna be rewritten by its creators in another language. That is highly doubtful considering the age of SQLite and the roadmap for support I think until 2060 or mid 2050s based on what I’ve read.
> SQLite is never gonna be rewritten by its creators in another language.
Almost certainly correct. It is however being rewritten in Rust by other people https://github.com/tursodatabase/turso. This is probably best thought of as a seperate, compatible project rather than a true rewrite.
Makes a lot of sense for SQLite to be written in C. It's a heavily optimized and debugged database implementation: Just look at btree.c with all its gotos :) The only language that would make sense for a partial/progressive migration is zig, in huge part due to its compatibility with C. It's not mentioned in the article though.
The amount of completely obscure and exotic platforms that have C compiler, and the amount of tooling and analysis tools C has — I'd be surprised anything comparable exists.