While there are a lot of good points there are some which are strange IMHO (wrt. the save language section): > import complete binary SQLite database files fr

While there are a lot of good points there are some which are strange IMHO (wrt. the save language section): > import complete binary SQLite database files from untrusted sources Standard sqlite3 contains features which makes opening databases from untrusted sources quite dangerous and as far as I know there is no "un-trusted" open mode, through you might be able to compile a hardened/restricted sqlite. Either way it's true that using a "safe" language would not have helped here. > 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. But sqlite favors the use of asserts and what this languages insert are basically asserts... > Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. This might be true about go (idk.) but isn't this generalizing a bit to much? Just to be clear that sqlite is and stays in C makes totally sense I just feel the author tries a bit to hard to find arguments beyond the necessary ones. I mean: - When it was written there where no chooseable "safe" language alternatives. - Sqlite is extremely well tested, many (most?) of the recent bugs where not of the kind any safe language would have prevented. - Safe languages don't necessarily help you with avoiding logic bugs. And while many do have additional abstractions/tooling to help with preventing logic bugs rewriting sqlite is more likely to introduce more logic bugs then it would prevent in the long runs. Rewrites are always a good chance to both fix bugs but also introduce new bugs. - Sqlite is extremely portable non of the safe languages have quite that level of portability sqlite wants to provide.