SQLite 選擇 C 語言的理由是辨泳？為什么不選擇 Go 或者 Rust？
1C 語言是最好的
SQLite 在 2000 年 5 月 29 日發(fā)布玖院，并一直使用 C 語言實(shí)現(xiàn)菠红。C 語言一直是實(shí)現(xiàn) SQLite 這類軟件庫的最佳語言，目前還沒有計(jì)劃使用其他編程語言重新開發(fā) SQLite难菌。
C 語言是實(shí)現(xiàn) SQLite 的最佳語言试溯，原因有四：性能、兼容性郊酒、低依賴性遇绞、穩(wěn)定性。
性能
像 SQLite 這樣低級庫速度必須要快燎窘。確實(shí)摹闽，SQLite 的速度很快，甚至比文件系統(tǒng)要快上 35％褐健。
C 語言非常適合用來開發(fā)這種對速度有要求的代碼付鹿。C 語言有時(shí)被稱為“可移植的匯編語言”。它讓開發(fā)人員能夠盡可能地靠近底層硬件蚜迅，同時(shí)仍然可以保持跨平臺(tái)可移植性舵匾。
有些語言聲稱自己“與 C 語言一樣快”，但卻沒有一門語言敢聲稱在作為通用目的編程時(shí)比 C 語言快谁不，因?yàn)檎娴臎]有坐梯。
兼容性
幾乎所有系統(tǒng)都能夠調(diào)用用 C 語言編寫的庫，但不一定都能調(diào)用使用其他語言實(shí)現(xiàn)的庫拍谐。
例如烛缔，使用 Java 開發(fā)的 Android 應(yīng)用程序也能調(diào)用 SQLite（通過適配器）馏段。如果使用 Java 開發(fā) SQLite轩拨，那么對 Android 來說可能會(huì)更加方便，因?yàn)榻涌跁?huì)更簡單院喜。但是亡蓉，在 iPhone 上，應(yīng)用程序是用 Objective-C 或 Swift 開發(fā)的喷舀，它們都不能調(diào)用使用 Java 編寫的庫砍濒。因此淋肾，如果使用 Java 開發(fā)，SQLite 將無法在 iPhone 上使用爸邢。
低依賴性
使用 C 語言開發(fā)的庫沒有太多運(yùn)行時(shí)依賴樊卓。SQLite 的最低配置只依賴標(biāo)準(zhǔn) C 庫的以下幾個(gè)例程：memcmp()、strcmp()杠河、memcpy()碌尔、strlen()、memmove()券敌、strncmp()唾戚、memset()。
對于更完整的版本待诅，SQLite 還使用了 malloc() 和 free() 之類的例程以及用于打開叹坦、讀取、寫入和關(guān)閉文件的操作系統(tǒng)接口卑雁。但即便如此募书，依賴項(xiàng)的數(shù)量仍然非常少。相比之下测蹲，其他“現(xiàn)代”語言通常需要加載數(shù)兆字節(jié)帶有成千上萬個(gè)接口的運(yùn)行時(shí)锐膜。
穩(wěn)定性
C 語言陳舊乏味，是一門眾所周知且易于理解的語言弛房。這正好契合了 SQLite 的要求道盏。如果沒有 C 語言這樣的語言，開發(fā)一個(gè)小型文捶、快速荷逞、可靠的數(shù)據(jù)庫引擎是很困難的。
小編給大家推薦一個(gè)學(xué)習(xí)氛圍超好的地方粹排，C/C++交流企鵝裙：487875004適合在校大學(xué)生种远，小白，想轉(zhuǎn)行顽耳，想通過這個(gè)找工作的加入坠敷。裙里有大量學(xué)習(xí)資料，有大神解答交流問題射富，每晚都有免費(fèi)的直播課程
2為什么 SQLite 不使用面向?qū)ο笳Z言來開發(fā)膝迎？
一些程序員無法想象怎么可以使用非“面向?qū)ο蟆钡恼Z言來開發(fā)像 SQLite 這樣的復(fù)雜系統(tǒng)。那么為什么 SQLite 沒有用 C++ 或 Java 來開發(fā)胰耗？
使用 C++ 或 Java 編寫的庫通常只能由以相同語言開發(fā)的應(yīng)用程序使用限次。使用 Haskell 或 Java 開發(fā)的應(yīng)用程序很難調(diào)用 C++ 庫。反過來，用 C 語言編寫的庫可以在其他編程語言中調(diào)用卖漫。
面向?qū)ο笫且环N設(shè)計(jì)模式费尽，而不是一種編程語言。你可以使用任何語言（包括匯編語言）實(shí)現(xiàn)面向?qū)ο缶幊萄蚴迹皇悄承┱Z言（例如 C++ 或 Java）讓面向?qū)ο笞兂勺兊酶菀锥押涤住５闳匀豢梢杂孟?C 這樣的語言進(jìn)行面向?qū)ο缶幊獭?/p>
面向?qū)ο蟛⒉皇俏ㄒ挥行У脑O(shè)計(jì)模式。很多程序員被教導(dǎo)使用純粹的面向?qū)ο蠓绞竭M(jìn)行思考突委。對象通常是分解問題的好方法速警，但對象不是唯一的方法，而且不一定是分解問題的最佳方法鸯两。有時(shí)候闷旧，過程式的代碼更容易編寫，更易于維護(hù)和理解钧唐，并且比面向?qū)ο蟮拇a運(yùn)行地更快忙灼。
最初在開發(fā) SQLite 時(shí)，Java 還只是一門年輕而不成熟的語言钝侠。C++ 比較成熟一些该园，但正在經(jīng)歷成長的痛苦時(shí)期，當(dāng)時(shí)很難找到兩種能夠以相同方式工作的 C++ 編譯器帅韧。所以里初，在當(dāng)時(shí) C 語言絕對是一個(gè)更好的選擇。現(xiàn)在這種情況沒有那么明顯忽舟，但現(xiàn)在重新開發(fā) SQLite 幾乎沒有任何好處双妨。
3為什么 SQLite 不使用“安全”的編程語言來開發(fā)？
最近人們對像 Rust 或 Go 這樣的“安全”編程語言很感興趣叮阅。在使用這些編程語言時(shí)刁品，不太可能或至少很難犯下常見的編程錯(cuò)誤，如內(nèi)存泄漏或數(shù)組溢出浩姥。因此挑随，經(jīng)常會(huì)有人問為什么 SQLite 不使用“安全”的語言來開發(fā)。
在 SQLite 出現(xiàn)后的頭 10 年中勒叠，所謂的安全的編程語言并不存在兜挨。SQLite 可以使用 Go 語言或 Rust 重新開發(fā)，但這樣做可能會(huì)引入更多的錯(cuò)誤眯分，并且也可能導(dǎo)致代碼運(yùn)行得更慢拌汇。
安全的編程語言解決了容易出現(xiàn)的問題：內(nèi)存泄漏、use-after-free 錯(cuò)誤颗搂、數(shù)組溢出等担猛。安全語言在解決 SQL 計(jì)算結(jié)果這個(gè)問題上，不會(huì)比普通的 C 語言代碼提供更多的幫助丢氢。
安全語言通常聲稱自己有助于防止安全漏洞傅联。話是沒錯(cuò)，但 SQLite 并不是一個(gè)對安全特別敏感的庫疚察。如果應(yīng)用程序運(yùn)行了不受信任且未經(jīng)驗(yàn)證的 SQL蒸走，那么它已經(jīng)存在更大的安全問題（SQL 注入），沒有哪一門“安全”的語言可以修復(fù)這個(gè)問題貌嫡。確實(shí)比驻，應(yīng)用程序有時(shí)會(huì)從不受信任的來源導(dǎo)入 SQLite 二進(jìn)制數(shù)據(jù)庫文件，這樣可能會(huì)帶來潛在的威脅岛抄。但是别惦，SQLite 中的這種代碼路徑是很有限的，并且經(jīng)過了良好的測試夫椭。SQLite 還為希望讀取不受信任數(shù)據(jù)庫的應(yīng)用程序提供了預(yù)驗(yàn)證例程掸掸，幫助應(yīng)用程序檢測潛在的威脅。
一些“安全”語言（例如 Go 語言）不喜歡使用 assert()蹭秋。但是使用 assert() 是保持 SQLite 可維護(hù)性的重要前提扰付。
安全語言會(huì)插入額外的分支邏輯來執(zhí)行其他一些操作，比如驗(yàn)證數(shù)組訪問是否越界仁讨。而在正確的代碼中羽莺，永遠(yuǎn)不會(huì)使用這些分支邏輯。這也意味著機(jī)器代碼不會(huì) 100％被測試到洞豁，而這卻恰好是 SQLite 質(zhì)量策略的重要組成部分盐固。
安全語言通常希望在遇到內(nèi)存不足（OOM）時(shí)終止運(yùn)行。SQLite 卻被設(shè)計(jì)成能夠從 OOM 中正痴尚恢復(fù)闰挡。目前還不知道該如何在安全語言中實(shí)現(xiàn)這一特性。
現(xiàn)在所有的安全語言都是新生兒礁哄。SQLite 的開發(fā)人員對計(jì)算機(jī)語言研究人員努力開發(fā)更容易长酗、更安全的編程語言表示贊賞，我們鼓勵(lì)他們繼續(xù)努力下去桐绒。但在實(shí)現(xiàn) SQLite 時(shí)夺脾，我們對陳舊乏味的 C 語言更感興趣。
SQLite 可能有一天會(huì)使用 Rust 重新開發(fā)茉继。由于 Go 語言討厭 assert()咧叭，因此不太可能使用 Go 語言。但使用 Rust 也只是一種可能性烁竭。如果要使用 Rust 重新開發(fā) SQLite菲茬，需要滿足一些先決條件：
Rust 需要變得更成熟，減慢演化速度，并且要變得更加陳舊乏味婉弹。
Rust 需要證明它可以用于構(gòu)建能夠在所有其他編程語言中調(diào)用的通用庫睬魂。
Rust 需要證明它可以生成適用于嵌入式設(shè)備的代碼，包括缺少操作系統(tǒng)的設(shè)備镀赌。
Rust 需要提供可以對二進(jìn)制文件進(jìn)行 100％分支覆蓋測試的工具氯哮。
Rust 需要提供一種能夠從 OOM 錯(cuò)誤中優(yōu)雅恢復(fù)的機(jī)制。
Rust 需要證明它可以完成 C 語言在 SQLite 中所做的各種工作而不會(huì)降低性能商佛。
