開、讀取、寫入和關閉文件的操作系統接口。但即便如此，依賴項的數量仍然非常少。相比之下，其他“現代”語言通常需要加載數兆字節帶有成千上萬個接口的運行時。
穩定性
C 語言陳舊乏味，是一門衆所周知且易於理解的語言。這正好契合了 SQLite 的要求。如果沒有 C 語言這樣的語言，開發一個小型、快速、可靠的數據庫引擎是很困難的。
其實做爲一個學習者，有一個學習的氛圍跟一個交流圈子特別重要這裏我推薦一個C語言C++交流羣1075673198，不管你是小白還是轉行人士歡迎入駐，大家一起交流成長。
2
爲什麼 SQLite 不使用面嚮對象語言來開發？
一些程序員無法想象怎麼可以使用非“面向對象”的語言來開發像 SQLite 這樣的複雜系統。那麼爲什麼 SQLite 沒有用 C++ 或 Java 來開發？
使用 C++ 或 Java 編寫的庫通常只能由以相同語言開發的應用程序使用。使用 Haskell 或 Java 開發的應用程序很難調用 C++ 庫。反過來，用 C 語言編寫的庫可以在其他編程語言中調用。
面向對象是一種設計模式，而不是一種編程語言。你可以使用任何語言（包括彙編語言）實現面向對象編程，只是某些語言（例如 C++ 或 Java）讓面向對象變成變得更容易而已。但你仍然可以用像 C 這樣的語言進行面向對象編程。
面向對象並不是唯一有效的設計模式。很多程序員被教導使用純粹的面向對象方式進行思考。對象通常是分解問題的好方法，但對象不是唯一的方法，而且不一定是分解問題的最佳方法。有時候，過程式的代碼更容易編寫，更易於維護和理解，並且比面向對象的代碼運行地更快。
最初在開發 SQLite 時，Java 還只是一門年輕而不成熟的語言。C++ 比較成熟一些，但正在經歷成長的痛苦時期，當時很難找到兩種能夠以相同方式工作的 C++ 編譯器。所以，在當時 C 語言絕對是一個更好的選擇。現在這種情況沒有那麼明顯，但現在重新開發 SQLite 幾乎沒有任何好處。
3
爲什麼 SQLite 不使用“安全”的編程語言來開發？
最近人們對像 Rust 或 Go 這樣的“安全”編程語言很感興趣。在使用這些編程語言時，不太可能或至少很難犯下常見的編程錯誤，如內存泄漏或數組溢出。因此，經常會有人問爲什麼 SQLite 不使用“安全”的語言來開發。
在 SQLite 出現後的頭 10 年中，所謂的安全的編程語言並不存在。SQLite 可以使用 Go 語言或 Rust 重新開發，但這樣做可能會引入更多的錯誤，並且也可能導致代碼運行得更慢。
安全的編程語言解決了容易出現的問題：內存泄漏、use-after-free 錯誤、數組溢出等。安全語言在解決 SQL 計算結果這個問題上，不會比普通的 C 語言代碼提供更多的幫助。
安全語言通常聲稱自己有助於防止安全漏洞。話是沒錯，但 SQLite 並不是一個對安全特別敏感的庫。如果應用程序運行了不受信任且未經驗證的 SQL，那麼它已經存在更大的安全問題（SQL 注入），沒有哪一門“安全”的語言可以修復這個問題。確實，應用程序有時會從不受信任的來源導入 SQLite 二進制數據庫文件，這樣可能會帶來潛在的威脅。但是，SQLite 中的這種代碼路徑是很有限的，並且經過了良好的測試。SQLite 還爲希望讀取不受信任數據庫的應用程序提供了預驗證例程，幫助應用程序檢測潛在的威脅。
一些“安全”語言（例如 Go 語言）不喜歡使用 assert()。但是使用 assert() 是保持 SQLite 可維護性的重要前提。
安全語言會插入額外的分支邏輯來執行其他一些操作，比如驗證數組訪問是否越界。而在正確的代碼中，永遠不會使用這些分支邏輯。這也意味着機器代碼不會 100％被測試到，而這卻恰好是 SQLite 質量策略的重要組成部分。
安全語言通常希望在遇到內存不足（OOM）時終止運行。SQLite 卻被設計成能夠從 OOM 中正常恢復。目前還不知道該如何在安全語言中實現這一特性。
現在所有的安全語言都是新生兒。SQLite 的開發人員對計算機語言研究人員努力開發更容易、更安全的編程語言表示讚賞，我們鼓勵他們繼續努力下去。但在實現 SQLite 時，我們對陳舊乏味的 C 語言更感興趣。
其實做爲一個學習者，有一個學習的氛圍跟一個交流圈子特別重要這裏我推薦一個C語言C++交流羣1075673198，不管你是小白還是轉行人士歡迎入駐，大家一起交流成長。
SQLite 可能有一天會使用 Rust 重新開發。由於 Go 語言討厭 assert()，因此不太可能使用 Go 語言。但使用 Rust 也只是一種可能性。如果要使用 Rust 重新開發 SQLite，需要滿足一些先決條件：
1：Rust 需要變得更成熟，減慢演化速度，並且要變得更加陳舊乏味。
2：Rust 需要證明它可以用於構建能夠在所有其他編程語言中調用的通用庫。
3：Rust 需要證明它可以生成適用於嵌入式設備的代碼，包括缺少操作系統的設備。
4：Rust 需要提供可以對二進制文件進行 100％分支覆蓋測試的工具。
5：Rust 需要提供一種能夠從 OOM 錯誤中優雅恢復的機制。
6：Rust 需要證明它可以完成 C 語言在 SQLite 中所做的各種工作而不會降低性能。