SQLite最近发表了一篇博文，解释了为什么SQLite多年来一直坚持用C语言实现。它是用C语言实现的。C一直是实现SQLite等软件库的首选语言。目前，没有计划用另一种语言重新开发SQLite。为什么C语言是实现SQLite的最佳选择？原因主要体现在这几个方面：PerformanceCompatibilityLowdependencyStability1.Performance像SQLite这样的库一定要快。SQLite非常快，它比文件系统快35%（有关详细信息，请参阅这两个示例：InternalVersusExternalBLOBs和35%FasterThanTheFilesystem）。C语言可以实现快速编写代码。C语言常被描述为“可移植的汇编语言”。它使开发人员能够尽可能接近底层硬件进行编码，同时仍然保持跨平台的可移植性。通常，我们可能会看到有人形容一门语言“和C语言一样快”，但是我们不会看到有人说通用编程有一种语言“比C语言还快”，因为这门语言真的很快。不存在。2.兼容性几乎所有的系统都可以调用C语言编写的库，而其他语言的则不行。例如，用Java编写的Android应用程序可以调用SQLite（通过适配器）。如果SQLite是用Java编写的，那么对于Android来说可能会更方便，因为这会使界面更简单。但在iPhone上，应用程序是用Objective-C或Swift编写的，它们都不能调用用Java编写的库。所以如果SQLite是用Java编写的，它就不能在iPhone上运行。3.依赖性低C语言编写的库对运行时的依赖性不强。SQLite的最佳配置也只需要C库中的这些方法：free()和用于打开、读取、写入和关闭文件的操作系统接口。但即使那样，依赖项的数量也很少。4.稳定性C语言简单易懂，符合SQLite的要求，适合SQLite的开发。为什么SQLite不使用面向对象的语言？开发者可能无法想象，用“非面向对象”的方式开发一个像SQLite这样复杂的系统会是什么样子。那么，为什么SQLite不是用C++或Java开发的呢？1.用C++或Java编写的库通常只能被用同一种语言编写的应用程序使用。用Haskell或Java编写的应用程序很难调用用C++编写的库。另一方面，可以从任何编程语言调用用C编写的库。2、面向对象是一种设计模式，不是编程语言。您可以使用任何您想要的语言进行面向对象编程，包括汇编语言。某些语言（例如：C++或Java）可以使面向对象变得更容易，但您仍然可以使用C等语言进行面向对象编程。3.面向对象并不是唯一有效的设计模式。对象通常是分解问题的好方法。但这不是唯一的方法，也不总是解决问题的最佳方法。有时，好的旧过程代码比面向对象的代码更容易编写、更容易维护和理解，而且速度更快。4.SQLite开发的时候，Java还不是成熟的语言，C++会更成熟，但是那个时候很难找到两个可以以同样的方式工作的C++编译器。相比之下，C语言是一个不错的选择。虽然，现在情况有所改善，但为此重新开发SQLite并没有任何好处。为什么SQLite不是用“安全”语言编写的？使用“安全”的语言不容易出现内存泄漏、数组溢出等安全问题。最近，很多人似乎对Rust和Go等“安全”语言感兴趣。但是为什么不使用SQLite呢？1.SQLite出现后的10年里，所谓的“安全”语言并不存在。虽然SQLite可以用Rust或Go重写，但这可能会引入更多难以修复的错误，进而影响编码速度。2、“安全”的编程语言解决的是简单的问题：像内存泄漏、数组溢出等，在解决SQL计算结果等问题上不如C语言好用。3.“安全”语言防止安全漏洞，但SQLite并不是一个安全敏感的库。如果应用程序运行不受信任的SQL，它可能已经存在无法通过“安全”语言修复的更大的安全问题。4.一些“安全”的语言（如Go语言）不喜欢使用assert()，但这是保持SQLite可维护性的重要前提。5.“安全”语言插入额外的机器分支来执行其他操作。但是在正确的代码中，这些分支不会被采用。所以机器码不能100%测试，但这恰恰是SQLite质检的重要一环。6.“安全”语言在内存不足（OOM）时会请求终止，而SQLite设计为遇到OOM时会恢复。目前，还不知道如何使用“安全”语言来做到这一点。7、现有的“安全”语言都比较新，SQLite的开发者很欣赏他们的出现，但仍然认为C语言更适合现在的开发工作。文章***表示，SQLite可能会考虑用Rust重新开发，但不太可能使用Go语言，因为它对assert()不友好。但实际上，Rust目前的条件还不足以重新开发SQLite，它还需要继续开发。
