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 来开发?

  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 可以使用 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 中所做的各种工作而不会降低性能。

本文来自infoq企业号

余下全文(1/3)
分享这篇文章:

请关注我们:

发表评论

电子邮件地址不会被公开。 必填项已用*标注