ハクソク

世界を動かす技術を、日本語で。

Cが最高です

2026年1月6日原文(sqlite.org)

概要

  • SQLiteは C言語 で実装されている理由の解説
  • パフォーマンス・互換性・依存性の低さ・安定性 が主な理由
  • オブジェクト指向言語や「安全な」言語で実装しない理由も説明
  • Rust など新しい言語への移行条件も記載
  • 今後も C言語 での開発継続予定

SQLiteがCで実装されている理由

  • C言語 はSQLiteのようなソフトウェアライブラリ実装に最適
  • 2000年5月29日から一貫して 汎用C で実装
  • 他言語への移行計画なし

主な理由

  • パフォーマンス

    • 頻繁に利用される低レベルライブラリには 高速性 が必須
    • Cは「 移植可能なアセンブリ言語」と評される
    • 他の言語も「C並みの速さ」とは言うが、「Cより速い」とは主張しない

  • 互換性

    • ほぼ全てのシステムが Cで書かれたライブラリ を呼び出し可能
    • Javaで書かれた場合、Androidでは便利でも iPhoneでは利用不可
    • Cで書くことで多様なプラットフォーム対応が可能

  • 依存性の低さ

    • Cで書かれたライブラリは ランタイム依存が非常に少ない
    • SQLiteの最小構成で必要な標準Cライブラリ関数はごくわずか
    • 他のモダン言語は巨大なランタイム依存や多数のインターフェースが必要

  • 安定性

    • Cは「 古くて退屈」な言語であり、仕様や挙動が安定
    • 実装言語の仕様変更リスクが少なく、信頼性重視の開発に最適

なぜオブジェクト指向言語で実装しないのか

  • C++やJavaで書かれたライブラリは 同言語以外からの利用が困難
  • Cなら どんな言語からも呼び出し可能
  • オブジェクト指向は 設計パターン であり、Cでも実現可能
  • オブジェクト指向だけが最良の設計手法ではない
  • SQLite開発当時、Javaは未熟、C++は互換性問題が多発
  • 現在も他言語への移行メリットはほぼなし

なぜ「安全な」言語で実装しないのか

  • RustやGoなどの「 安全な言語」はSQLite誕生から10年以上存在しなかった
  • 安全な言語での再実装は 新たなバグやパフォーマンス低下 リスク
  • 安全な言語は 実行時検証 による分岐追加があり、完全なテストが困難
  • SQLiteは メモリ不足時も優雅に復旧 する設計だが、安全な言語は通常abort
  • Rustのような新言語は 成熟・安定・移植性・ツール類 がまだ十分でない
  • Goは assert() の扱いがSQLiteの方針と合わないため移行は非現実的

Rustへの移行のための条件

  • Rustの 成熟度・安定性の向上

  • 他言語からの 汎用ライブラリ呼び出し 実現

  • 組込み機器 やOS非搭載デバイスでの動作実績

  • 100%分岐カバレッジテスト 対応ツールの整備

  • OOM（メモリ不足）時の優雅な復旧 機構の実装

  • C並みの速度 でSQLiteの処理を実現できること

  • Rustコミュニティからの提案や働きかけも歓迎

まとめ

  • SQLiteは C言語 による実装を今後も継続予定
  • パフォーマンス・互換性・安定性・依存性の低さ を重視
  • 新言語への移行は慎重に検討される方針

Hackerたちの意見

Rustには、OOMエラーから優雅に回復するためのメカニズムが必要だよね。Linusもこれについて言及してたし。https://lkml.org/lkml/2021/4/14/1099

└

彼の言ってることは間違ってないけど、もうちょっと自分のところを整理した方がいいね。

└

Rustの言語機能はどれもメモリを割り当てないよ。配列も、クロージャも、イテレータもね。デフォルトではすべてスタックに割り当てられる。Rustのコードは、mallocを呼び出すライブラリを使わない限り、mallocしないんだ。つまり、Cと全く同じ。Rustはメモリ割り当てを行う標準ライブラリの部分をオフにすることを完全にサポートしていて、これがまさに組み込みコードやLinuxカーネルがやってることなんだ。だから、Rustはすでに完全なコントロールを提供してるよ。

この文章の最後のコメントは冷静で、変化に対するオープンさを示してるね。最近、RediSearchをRustに移行するプロジェクトに取り組んでたんだけど、これは最近のCVEsが結構あったからなんだ。SQLiteがこの問題を抱えてないなら、Rustに移行するための他の強い理由が必要だと思う。Rustが得意な範囲を理解するには、かなりの時間がかかると思うし、数十年かかるかもしれないね。例えば、個人的にはRustがGUIアプリケーションにどれだけ向いてるのかはよく分からないな。

└

C以外の言語を使うというアイデアをすぐに却下しないのはいいね（結論は、ここにある編集されたタイトルが示唆するほどドグマ的ではないし、実際のページのタイトルは「SQLiteはなぜCで書かれているのか？」だから）。でも、Cが今享受している安定性や「退屈さ」は、実際に数十年かけて実現されたものだってことははっきりさせておこう（ANSI C以前は、ECMAのJavascriptと比べても野蛮な状況だった）。他の言語にも同じ自由度を与えると、少なくとも2040年まではRustを使うことはないんじゃないかな。

└

SQLiteのようなものには、Ada/SPARKの方が良い選択かもしれないね。

2017年には少なくとも[1]だけど、「このページは2025-05-09 15:56:17Zに最終更新されました。」 [1] https://web.archive.org/web/20170701061906/https://sqlite.or...

└

もっと更新されると思うよ。

└

スティーブ・イェッゲがガスタウンを解き放って、コンボイかなんかでSQLiteをRustで書き直してほしいな。もちろん100%のテストカバレッジは維持してね。結果は成功するか失敗するかに関わらず、間違いなく衝撃的なものになると思う。

どのプロジェクトやプログラマーも、Rust（またはZig）を使わない選択を正当化しなきゃいけないなんて思う必要はないよ。特にHacker Newsや特定のSNSで不自然に押されてる感じがするからね。最近は少し減ったけど、OOPを使うプレッシャーもあったし。もしCでOOPなしで良い結果を出していて、みんながその製品を気に入っているなら、外部の人がそのプロジェクトに口を出すべきじゃないと思う。それは彼らのプロジェクトなんだから。

└

TidesDBについては、これをよく聞かれるんだ。「なんでRustを選ばなかったの？」って。まあ、これは本当に一般的な質問だね。いいコメントだ。

└

我々（特に経営陣）は、常に新しいものを求めるように訓練されているんだ。それに、簡単なセリフでもあるしね。

Hacker Newsで議論の続きを見る