发布至今18年，为什么SQLite一定要用C语言来开发？

C语言是最好的

SQLite在2000年5月29日发布，并一直使用C语言实现。C语言一直是实现SQLite这类软件库的最佳语言，目前还没有计划使用其他编程语言重新开发SQLite。

C语言是实现SQLite的最佳语言，原因有四：性能、兼容性、低依赖性、稳定性。

性能

像SQLite这样低级库速度必须要快。确实，SQLite的速度很快，甚至比文件系统要快上35％。

C语言非常适合用来开发这种对速度有要求的代码。C语言有时被称为“可移植的汇编语言”。它让开发人员能够尽可能地靠近底层硬件，同时仍然可以保持跨平台可移植性。

有些语言声称自己“与C语言一样快”，但却没有一门语言敢声称在作为通用目的编程时比C语言快，因为真的没有。

兼容性

几乎所有系统都能够调用用C语言编写的库，但不一定都能调用使用其他语言实现的库。

例如，使用Java开发的Android应用程序也能调用SQLite（通过适配器）。如果使用Java开发SQLite，那么对Android来说可能会更加方便，因为接口会更简单。但是，在iPhone上，应用程序是用Objective-C或Swift开发的，它们都不能调用使用Java编写的库。因此，如果使用Java开发，SQLite将无法在iPhone上使用。

低依赖性

使用C语言开发的库没有太多运行时依赖。SQLite的最低配置只依赖标准C库的以下几个例程：memcmp()、strcmp()、memcpy()、strlen()、memmove()、strncmp()、memset()。

对于更完整的版本，SQLite还使用了malloc()和free()之类的例程以及用于打开、读取、写入和关闭文件的操作系统接口。但即便如此，依赖项的数量仍然非常少。相比之下，其他“现代”语言通常需要加载数兆字节带有成千上万个接口的运行时。

稳定性

C语言陈旧乏味，是一门众所周知且易于理解的语言。这正好契合了SQLite的要求。如果没有C语言这样的语言，开发一个小型、快速、可靠的数据库引擎是很困难的。

为什么SQLite不使用面向对象语言来开发？

一些程序员无法想象怎么可以使用非“面向对象”的语言来开发像SQLite这样的复杂系统。那么为什么SQLite没有用C++或Java来开发？

使用C++或Java编写的库通常只能由以相同语言开发的应用程序使用。使用Haskell或Java开发的应用程序很难调用C++库。反过来，用C语言编写的库可以在其他编程语言中调用。\\t
面向对象是一种设计模式，而不是一种编程语言。你可以使用任何语言（包括汇编语言）实现面向对象编程，只是某些语言（例如C++或Java）让面向对象变成变得更容易而已。但你仍然可以用像C这样的语言进行面向对象编程。\\t
面向对象并不是唯一有效的设计模式。很多程序员被教导使用纯粹的面向对象方式进行思考。对象通常是分解问题的好方法，但对象不是唯一的方法，而且不一定是分解问题的最佳方法。有时候，过程式的代码更容易编写，更易于维护和理解，并且比面向对象的代码运行地更快。\\t
最初在开发SQLite时，Java还只是一门年轻而不成熟的语言。C++比较成熟一些，但正在经历成长的痛苦时期，当时很难找到两种能够以相同方式工作的C++编译器。所以，在当时C语言绝对是一个更好的选择。现在这种情况没有那么明显，但现在重新开发SQLite几乎没有任何好处。\

为什么SQLite不使用“安全”的编程语言来开发？

最近人们对像Rust或Go这样的“安全”编程语言很感兴趣。在使用这些编程语言时，不太可能或至少很难犯下常见的编程错误，如内存泄漏或数组溢出。因此，经常会有人问为什么SQLite不使用“安全”的语言来开发。

在SQLite出现后的头10年中，所谓的安全的编程语言并不存在。SQLite可以使用Go语言或Rust重新开发，但这样做可能会引入更多的错误，并且也可能导致代码运行得更慢。\\t
安全的编程语言解决了容易出现的问题：内存泄漏、use-after-free错误、数组溢出等。安全语言在解决SQL计算结果这个问题上，不会比普通的C语言代码提供更多的帮助。\\t
安全语言通常声称自己有助于防止安全漏洞。话是没错，但SQLite并不是一个对安全特别敏感的库。如果应用程序运行了不受信任且未经验证的SQL，那么它已经存在更大的安全问题（SQL注入），没有哪一门“安全”的语言可以修复这个问题。确实，应用程序有时会从不受信任的来源导入SQLite二进制数据库文件，这样可能会带来潜在的威胁。但是，SQLite中的这种代码路径是很有限的，并且经过了良好的测试。SQLite还为希望读取不受信任数据库的应用程序提供了预验证例程，帮助应用程序检测潜在的威胁。\\t
一些“安全”语言（例如Go语言）不喜欢使用assert()。但是使用assert()是保持SQLite可维护性的重要前提。\\t
安全语言会插入额外的分支逻辑来执行其他一些操作，比如验证数组访问是否越界。而在正确的代码中，永远不会使用这些分支逻辑。这也意味着机器代码不会100％被测试到，而这却恰好是SQLite质量策略的重要组成部分。\\t
安全语言通常希望在遇到内存不足（OOM）时终止运行。SQLite却被设计成能够从OOM中正常恢复。目前还不知道该如何在安全语言中实现这一特性。\\t
现在所有的安全语言都是新生儿。SQLite的开发人员对计算机语言研究人员努力开发更容易、更安全的编程语言表示赞赏，我们鼓励他们继续努力下去。但在实现SQLite时，我们对陈旧乏味的C语言更感兴趣。\

SQLite可能有一天会使用Rust重新开发。由于Go语言讨厌assert()，因此不太可能使用Go语言。但使用Rust也只是一种可能性。如果要使用Rust重新开发SQLite，需要满足一些先决条件：

Rust需要变得更成熟，减慢演化速度，并且要变得更加陈旧乏味。\\t
Rust需要证明它可以用于构建能够在所有其他编程语言中调用的通用库。\\t
Rust需要证明它可以生成适用于嵌入式设备的代码，包括缺少操作系统的设备。\\t
Rust需要提供可以对二进制文件进行100％分支覆盖测试的工具。\\t
Rust需要提供一种能够从OOM错误中优雅恢复的机制。\\t
Rust需要证明它可以完成C语言在SQLite中所做的各种工作而不会降低性能。\

英文原文：https://sqlite.org/whyc.html