跳到正文
Back to Feed

总结

一篇来自 HackerNews 的技术解读称,自2000年5月29日诞生以来,SQLite 一直以通用 C 语言实现,当前也无意用其他语言重写。团队认为C在性能、跨平台兼容性、低依赖与语言规范稳定性上最适合做可嵌入数据库库:执行更接近底层、几乎可被各系统与语言调用,并在最小配置下仅依赖少量标准库函数。针对面向对象与“安全语言”疑问,团队表示C同样可实现面向对象设计;转向Rust/Go等可能带来额外检查分支影响性能与100%分支覆盖策略,且部分语言在OOM时易中止。未来不排除使用Rust,但需满足成熟度、互操作、嵌入式支持与测试/OOM机制等条件。

正文

💻 SQLite 坚持使用 C 语言开发的核心原因与考量 自 2000 年 5 月 29 日诞生以来,SQLite 始终采用通用 C 语言实现,且目前没有计划使用其他语言重写。开发者认为 C 语言在性能、兼容性、低依赖性和稳定性方面是实现 SQLite 这类软件库的最佳选择。在性能方面,C 语言作为"可移植的汇编语言",允许开发者尽可能接近底层硬件,目前没有其他通用编程语言在执行速度上超越 C。在兼容性上,C 语言编写的库几乎可以被所有系统和编程语言调用,这使得 SQLite 能够跨平台支持 Android(Java)和 iPhone(Objective-C/Swift)等不同环境。此外,SQLite 对外部依赖极低,在最小配置下仅需 memcmp、memcpy 等少数标准 C 库函数,无需像现代语言那样加载数兆字节的运行时环境。C 语言的成熟与稳定也确保了开发过程不会因语言规范的频繁变动而受到干扰。 针对为何不使用面向对象语言或"安全"语言的疑问,SQLite 团队提供了明确的技术解释。开发者指出,面向对象是一种设计模式而非语言限制,C 语言同样可以实现面向对象设计,且 C 语言库比 C++ 或 Java 库更易于被跨语言调用。关于 Rust 或 Go 等安全语言,SQLite 诞生前十年这些语言尚未出现。目前不转用此类语言的原因在于,安全语言引入的额外分支检查(如数组越界检查)可能导致代码变慢,且这些永远不会被执行的检查分支会导致机器码无法通过 SQLite 质量策略要求的 100% 分支测试。同时,SQLite 能够从内存不足(OOM)的情况中优雅恢复,而许多安全语言在 OOM 时倾向于直接中止。虽然 SQLite 团队不排除未来使用 Rust 的可能性,但前提是 Rust 需在成熟度、跨语言调用能力、嵌入式设备支持、分支覆盖测试工具以及 OOM 处理机制等方面满足特定要求。 (HackerNews)
发布时间: