SQLite：C 是最好的，没有比 C 更快的语言

大家的板块 青蛙的分享
,
1

在 SQLite 官网有一篇名为《为什么 SQLite 是用 C 语言编写的》的文章，开头就用了两句非常简短但有力的话：

  1. C 是最好的
  2. 没有比 C 更快的语言

来证明这个标题：为什么 SQLite 是用 C 语言编写的

性能

就性能来说，像 SQLite 这样频繁使用的底层库需要足够快。（SQLite 确实很快），C 语言是编写快速代码的绝佳语言，其他编程语言有时会声称“和 C 一样快”。但没有其他语言声称在通用编程方面比 C 更快，因为实际上没有比 C 更快的语言。

兼容性

就兼容性来说，几乎所有系统都具有调用 C 编写的库的能力。

低依赖性

就低依赖性来说：用 C 编写的库不会依赖很多运行时，而其他“现代”语言通常需要加载数千个接口的数兆字节运行时。

稳定性

C 是一种“老、稳、无惊喜”的语言。对一个追求长期稳定的项目来说，这比花哨的新语法更重要。

所以，SQLite 是用 C 语言编写的

原文：Why Is SQLite Coded In C

2

用c确实很爽，让你有种掌控一切的感觉

3

写后台无界面的，确实c很好也足够了
但如果高并发，难度大很多

4

UB: ??

个人而言，希望能够是 c with classes, w/o UB, 再加上现代的包管理等工具链

5

用 SQLite 的都能飞上天了 :laughing:

6

我很尊重 SQLite 的开发者，也给 SQLite 写过 C 扩展。但这篇文章论证「C 最好」的论据显然有偏颇。

1. 性能：C 确实很快，但「没有比 C 更快的语言」就是瞎扯了。带有自动 SIMD 的语言，例如 Zig，显然有潜力比 C 更快。没有足够手动优化的时候，C++ 都可以比 C 快得多。

当然你可以争论说，有些现代 C 编译器支持自动 SIMD，并且 C 程序员也可以手动调用 SIMD 函数。那在这个前提下，所有编译型语言都有优化得和 C 一样快的潜力。

更不用说 I/O 场景下，内存模型、并发模型和切换上下文的成本才决定性能了。这种时候，同水平的程序员编写的 Java 也会比 C 快得多。

2. 兼容性：C 确实能兼容最广泛的硬件，但「兼容」和「可移植」是不一样的。由于 C 的标准库设计非常保守、功能零碎、编译器实现碎片化，要编译到各平台，由于使用的编译器不同，通常需要为每种编译器单独编写实现。最后实际上大大增加了工作量。

3. 低依赖性：这个实在不敢苟同。我要提出的观点是 C 是我见到的依赖地狱最严重、管理最混乱、用户安装软件成本最高的语言。只要你走过几个大型 C 项目的从开发到分发的流程，你就会知道这语言的开发体验从上到下都烂透了。包括但不限于：

  • 编译器 Flags 相互不完全兼容，LSP 体验差（目前只有 clangd 堪堪能用，但 clangd 只支持 clang 编译器…）
  • 同一项目依赖 Makefile、Autotools、CMake、conan、Meson 项目，五世同堂
  • Glibc 新旧版本不兼容，老系统运行直接报错。还有 musl-libc、Bionic 行为不一致。同一个软件要在干净环境（如 Docker）中编译几十次、分发几十种包
  • 至于说「其他语言要依赖数 MB 的运行库」。笑死，C 就不用依赖数 MB 的 libc 了吗？只不过发行版预装了而已。如果「发行版预装 = 不算占空间」，那我也可以说 Python 不需要任何运行库了
  • 不同 Linux 发行版打包系统不互相兼容。要发布到源里，需要开发者为每种发行版自行编写定义脚本。甚至像 Ubuntu 这样的还需要自己运行打包服务器，并且让用户添加自定义源。用户和开发者一起难受
  • 只要见过那种要求你 apt install lib-xxxx (一百种不同 lib)…… 再 make && sudo make install 的项目，你就明白我在说什么了

4. 稳定性：你稳我笑。C 是未定义行为（Undefined Behaviors）最多的语言之一，我见过的每五个项目里就有一个（由于程序员粗心或者别的原因），依靠编译器 Bug 或未定义语法运行。换个编译器或升级一下版本，立刻编译报错了。无惊喜？反正每次编译大型项目报的诡异错误给我的惊喜都挺多的。

1 个赞
7

不知道开发者到底是怎么做到的，不过看到这里猛然间想起来玩 Java 的还可以用 HSQLDB

8

同意！ 其实不仅适用于C！没有足够的能力，用越偏向低层的语言写出来的程序可能性能越差，稳定性也差！ 所谓越偏低层性能越好是建立在有足够的能力，且还有足够的时间成本、开发成本优化的情况下！