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

作者 | SQLite

译者 | 薛命灯

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

1 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 语言这样的语言，开发一个小型、快速、可靠的数据库引擎是很困难的。

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

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

1. 使用 C++ 或 Java 编写的库通常只能由以相同语言开发的应用程序使用。使用 Haskell 或 Java 开发的应用程序很难调用 C++ 库。反过来，用 C 语言编写的库可以在其他编程语言中调用。

2. 面向对象是一种设计模式，而不是一种编程语言。你可以使用任何语言（包括汇编语言）实现面向对象编程，只是某些语言（例如 C++ 或 Java）让面向对象变成变得更容易而已。但你仍然可以用像 C 这样的语言进行面向对象编程。

3. 面向对象并不是唯一有效的设计模式。很多程序员被教导使用纯粹的面向对象方式进行思考。对象通常是分解问题的好方法，但对象不是唯一的方法，而且不一定是分解问题的最佳方法。有时候，过程式的代码更容易编写，更易于维护和理解，并且比面向对象的代码运行地更快。

4. 最初在开发 SQLite 时，Java 还只是一门年轻而不成熟的语言。C++ 比较成熟一些，但正在经历成长的痛苦时期，当时很难找到两种能够以相同方式工作的 C++ 编译器。所以，在当时 C 语言绝对是一个更好的选择。现在这种情况没有那么明显，但现在重新开发 SQLite 几乎没有任何好处。

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

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

1. 在 SQLite 出现后的头 10 年中，所谓的安全的编程语言并不存在。SQLite 可以使用 Go 语言或 Rust 重新开发，但这样做可能会引入更多的错误，并且也可能导致代码运行得更慢。

2. 安全的编程语言解决了容易出现的问题：内存泄漏、use-after-free 错误、数组溢出等。安全语言在解决 SQL 计算结果这个问题上，不会比普通的 C 语言代码提供更多的帮助。

3. 安全语言通常声称自己有助于防止安全漏洞。话是没错，但 SQLite 并不是一个对安全特别敏感的库。如果应用程序运行了不受信任且未经验证的 SQL，那么它已经存在更大的安全问题（SQL 注入），没有哪一门“安全”的语言可以修复这个问题。确实，应用程序有时会从不受信任的来源导入 SQLite 二进制数据库文件，这样可能会带来潜在的威胁。但是，SQLite 中的这种代码路径是很有限的，并且经过了良好的测试。SQLite 还为希望读取不受信任数据库的应用程序提供了预验证例程，帮助应用程序检测潜在的威胁。

4. 一些“安全”语言（例如 Go 语言）不喜欢使用 assert。但是使用 assert 是保持 SQLite 可维护性的重要前提。

5. 安全语言会插入额外的分支逻辑来执行其他一些操作，比如验证数组访问是否越界。而在正确的代码中，永远不会使用这些分支逻辑。这也意味着机器代码不会 100％被测试到，而这却恰好是 SQLite 质量策略的重要组成部分。

6. 安全语言通常希望在遇到内存不足（OOM）时终止运行。SQLite 却被设计成能够从 OOM 中正常恢复。目前还不知道该如何在安全语言中实现这一特性。

7. 现在所有的安全语言都是新生儿。SQLite 的开发人员对计算机语言研究人员努力开发更容易、更安全的编程语言表示赞赏，我们鼓励他们继续努力下去。但在实现 SQLite 时，我们对陈旧乏味的 C 语言更感兴趣。

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

1. Rust 需要变得更成熟，减慢演化速度，并且要变得更加陈旧乏味。

2. Rust 需要证明它可以用于构建能够在所有其他编程语言中调用的通用库。

3. Rust 需要证明它可以生成适用于嵌入式设备的代码，包括缺少操作系统的设备。

4. Rust 需要提供可以对二进制文件进行 100％分支覆盖测试的工具。

5. Rust 需要提供一种能够从 OOM 错误中优雅恢复的机制。

6. Rust 需要证明它可以完成 C 语言在 SQLite 中所做的各种工作而不会降低性能。

英文原文

今日荐文

点击下方图片即可阅读

十多年前的那些工程师都去哪里了？

CNUTCon 全球 运维 技术大会 将于 2018 年 11 月 16 日 -17 日在上海举办，本届 CNUTCon 面向各行业对运维 & 容器技术感兴趣的中高端技术人员，聚焦 AIOps 相关技术及优秀实践，AI 和运维的结合，到底会带来哪些颠覆？有哪些新技术应运而生？企业在 AIOps 的落地实践中，都遇到过哪些问题和挑战，踩过哪些坑？他们又是如何解决的？未来又有哪些发展趋势？我们邀请了众多国内外知名企业的一线技术专家现场为你揭晓。

目前优惠进行中，快来抢票吧！更多详情可点击 阅读原文 查看。