SQLite为何要用C语言来开发？

SQLite 选择 C 语言的理由是？为什么不选择 Go 或者 Rust？

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

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

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

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

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

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