> The thing is, SQLite is bulletproof at this point, so do we need to replace it?

No, probably not, it is fine as it is. Still, even SQLite started out as a "for fun" project. Who knows what might happen in the future to displace it? ;)

Sqllite didn’t start for fun it was built for navy destroyers and submarines. (1) that’s probably why parent called it bulletproof.

(1) https://en.wikipedia.org/wiki/SQLite#History

It could also be a reference to the comprehensive SQLite test suite (1) or the fact that it has been in production systems for many years, though it’s initial purpose does make bulletproof quite apt.

(1) https://sqlite.org/testing.html

> Sqllite didn’t start for fun it was built for navy destroyers and submarines.

Those aren't mutually exclusive. I for one find destroyers to be an absolute riot.

I admit that I was merely being metaphorical and referencing the comprehensive test suite, wide distribution and usage.

I wish I had intended that pun embedded in the comment, but from now on ;)

When Wikipedia simply says otherwise I wonder where you got the "for fun" reference from. I tend to almost blindly trust comments on HN but this one was quite off.

You baited me into making an account.

See https://changelog.com/podcast/201#transcript-100

>I had couple months off and I thought, "Hey, I'm just gonna go and cobble together a really quick and simple database engine that just does a few very simple SQL commands, insert the lead, update and select." No joints, wasn't trying to be efficient... All I needed to do was pull stuff off of a disk in that memory.

>And I put it out there and... I've been doing open source for years before this, putting things on my website, and people would find my thing -- or well, you know, I'd put things on my website and it'd get like five downloads per year, or something like that. I'd figured this would be just another one of those things, but for whatever reason it really resonated with people.

> The thing is, SQLite is bulletproof at this point, so do we need to replace it?

Nothing written in C is bulletproof.

You're free to write bugs in any language. C just makes them easier to write or more critical.

OpenSSL was thought to be "bulletproof" and the "go to" option. And look where we are now

SQLite has a much more thorough testing process than OpenSSL did. Their acceptance tests have 100% MC/DC coverage [1], for example. While previous things like the IOC tester did find issues with SQLite, SQLite is very aggressive about including these sorts of tools into their ongoing testing process.

[1] MC/DC coverage is a slightly more rigorous form than branch coverage. A condition if (a && b) requires that you only test one of (a false, b true) and (a false, b false) for 100% coverage, whereas MC/DC coverage would insist on both being tested.

OpenSSL has always been nowhere near the level of robustness and bulletproofness that SQLite is at. Just look at how it's tested: https://www.sqlite.org/testing.html

It's too bad some part of tests are proprietary. I think it someone would want to rewrite SQLite (keeping compatibility), those tests would be of huge value.

Yes, but that is also a source of funding for the project.

And how many more critical flaws would OpenSSL have if people kept rewriting it in the trending language of the week?

Rewriting just for the sake of rewriting or because you like another language better is an almost certain recipe for disaster.

I have a hard time believing this. It was common knowledge and lamented before Heartbleed that OpenSSL was bloated an unwieldy. People were surprised by the severity, not that it happened.

I don't think this comparison is fair. SQLite is widely regarded as one of the best codebases in the world and it has 100% test coverage.

That level of test coverage isn't as meaningful as people think. I'd bet that a significant fraction (> 10%) of those tests are redundant or cost more (in terms of maintenance, for one example) than the value they provide.

I think you should read the full write-up on sqlite testing:

https://www.sqlite.org/testing.html

There's no question that sqlite is one of the most well understood and reliable codebases in the world.

OpenSSL is known to have a poorly documented, spaghetti codebase. The same is not true for SQLite.

Bob Beck during his LibreSSL talk had a good overview of what was thought of OpenSSL https://youtu.be/GnBbhXBDmwU?t=2m11s

"we are all guilty"

I suspect there's a huge code quality difference between OpenSSL and SQLite. Also, keep in mind that SQLite was much easier to fuzz - it's basically one of the libraries that AFL has specific features for (dictionary-based coverage-guided fuzzing).

OpenSSL was never thought to be bulletproof. It is, however, the best of the worst for many scenarios.

But it was bulletproof until proven otherwise.