I've refrained to comment about the OP linked page but I can't resist that long. I won't enter the C, C--, C++, C#, Java, Python, COBOL, Basic, assembler, Ruby, YouNameIt sub-debate.
I found the rant on MozillaWiki way too wrong on too many points to keep quiet. While I can agree with some of the most obvious "don't be dumb" remarks, there are many things that can't be let unchallenged. And I don't appreciate the overall tone: "WE at MozillaBigBalls are all clever enough to use SQLite smartly but you mere mortals are not, so don't even think to use that fragile piece of softawre." In it's introduction, the blurb talks about SQLite hidden complexity. Then it avdises Mozilla pluggin developers to avoid SQLite at almost any rate, due to "performance reasons", and recommends compressed JSON/logs instead. That's very odd, to say the least. All regular readers of this list have seen a number of threads where the intricacies of how hard it is to guarantee both some concurrency and ACID properties down to magnetic surface or chips' gates is difficult in the general case. You all know that SQLite actually uses all possible steps to bring this guarantee the closest possible to reality. Yet this guy(s) advocate that *-every-* pluggin devs should independently roll his own storage layer mostly from scratch, while pointing out the unstabilityor uncertainty associated with mobile devices processes/OSes. That is nothing but calling for (1) huge number of new entertaining bugs (2) at best, duplicate efforts to make that work in a highly multi-threaded environment where concurrency will need to be dealt with with greatest care. No, the "average" pluggin dev won't be able to come up in minutes with a rock solid storage layer portable to a myriad of platforms. And this is precisely what SQLite has been thru over years. As has already been pointed out, storing largish private data in compressed JSON or log file(s) will be (beyond often being a greater resource hog) a real nightmare when several tabs/windows will possibly need to concurrently read/modify/write stuff in there. Writing rants about SQLite being a resource hog and a performance breaker is one thing, guiding towards a clean way to replace it in practice is another (mystical) beast, at least for the average pluggin developper. Then another question remains: instead of putting the onus on SQLite being huge (footprint) and slow (CPU, the 22s "example"), why don't the author(s) of the blurb question the real root causes of the evil they condemn and openly recognize that the problem lies entirely elsewhere, perhaps in Mozilla core code design itself? They almost silently agree that allowing main-thread SQL access is a huge no-no. They recognize that allowing unlimited use of various (possibly conflicting) pragmas, random schemas and/or statements could harm. But what those hypocritical guys don't tell you is that the root cause is in the cahotic spiralling development history of Mozilla. After all, it's Mozilla devs themselves who designed pluggin APIs and let "spurious main-thread SQL statements" be possible. If they were sooo clever, they would never had allowed that and they also would have wrapped SQLite interface in a strictly limited set of rules enforced by a safe API. That, they won't tell you. Also, if Mozilla devs were sooo much more clever than average Joe and sooo caring about performance, they certainly would have fixed the hundreds of memory leaks that plague FF users (at least on Windows and for almost a decade) and they would have "spring cleaned" their messy codebase so that one can't see JS fragments kept running after the FF tabs which launched it was closed and blatant bugs like these. Watch memory bytes slowy growing toward 2Gb while FF is left "idle" and the RJ45 unplugged, without any pluggin set up... Is that the fault of pluggin devs, Dr. Hipp laziness, or the result of their own careless work? With today's FF W7 x64 (ditto for x86) release, you can't let it have, say, 30 tabs open 24/7 on "passive" forum pages (no ads, no sound, no video, nothing dynamic) for more than 2-3 weeks on the average. Then the machine gets so slow and unresponsive that you can only kill FF and restart it. At the time it has reopen and refreshed all the tabs, you witness its memory bytes now sit at 600 Mb (compared to ~2Gb before), with everything as functional as before killing it. Is that also SQLite fault or is that a sad joke? These are things that you don't see with either IE or Chrome (each of them having their own drawbacks too). In short and beyond a few trivial advises, the authors of this rant are either surprisingly ignorant or utterly hypocritical, but unfair at any rate. I've nothing against Mozilla per se and I sincerely acknowledge that maintaining such a huge open product is very hard, but this page is simply plain wrong.
