我們想要找一種低級語言來代替C，然而找不到；這并非是因為C語言是低級語言，相反，恰恰是因為C語言作為底層機器上的高層抽象太成功了。它如此成功，以至于讓大多數(shù)的低級語言顯得毫無意義。C就是這么擅長它所做的。

C語言的語法和語義強大而直觀。它可以用以編寫高級算法，同時也可以用以處理底層硬件邏輯。正因為其強大、簡單和直觀的語法和語義，C語言并不會給我們一些額外的認知上的負擔(dān)，從而讓編程者專注于真正重要的事情。

C顛覆了我們對低級語言的認識。這真了不起。

簡單的代碼，精致的類型

c語言是一種弱類型語言，其類型系統(tǒng)非常簡單。和C++還有java明顯的一個區(qū)別是，c里面你不能定義“類”（class），你不可以把所有的運行時需要的東西都放到“類”里面。你的所有工作都嚴(yán)格基于結(jié)構(gòu)（struct）和聯(lián)合（union）。所有的函數(shù)調(diào)用者必須明確被調(diào)用函數(shù)的參數(shù)類型和返回值類型。所以調(diào)用者的自由相對有限。

你只是想要個香蕉，結(jié)果來了只自稱森林之王的大猩猩——Joe Armstrong

你剛剛聽起來像是c語言缺點的東西某種程度上確實一種優(yōu)點：c語言的API面對用戶都力圖精簡。這避免了龐雜的框架，而力圖在簡單的類型基礎(chǔ)上創(chuàng)造一個小巧的函數(shù)庫。

而面向?qū)ο蟮恼Z言往往在復(fù)雜的類型基礎(chǔ)上又構(gòu)造了龐雜的基礎(chǔ)類庫，這些庫提供了大量的相互依賴的接口，他們的參數(shù)和返回值的“類”型也因此更加復(fù)雜。每一種“類”又定義了大量的復(fù)雜的方法和屬性……好吧，更加復(fù)雜了。

這并不是說吐面向?qū)ο缶拖Ｍ儚?fù)雜，但是他們貌似鼓勵你把事情變復(fù)雜。他們的復(fù)雜性使你很容易犯錯誤。相對來說，c就很少導(dǎo)致錯誤。c語言盡力構(gòu)建一個簡潔、通俗的類型系統(tǒng)，使用它你會發(fā)現(xiàn)你不需要顧及那么多的依賴關(guān)系。這使你的開發(fā)變得更加簡單。

速度之王

c語言不論在處理器中還是在內(nèi)存堆棧里，都是速度最快的。而且其高效不僅僅體現(xiàn)在速度上，即使是內(nèi)存的管理以及啟動時間上，也無人望其項背。當(dāng)你需要平衡空間和時間的消費時，c語言從來不會對你隱藏任何細節(jié)，原因如下：

每次那些更高層次的編程語言（比如java或者haskell），聲稱自己能產(chǎn)生接近c語言的表現(xiàn)從程序的時候，這在我聽來簡直就是笑話。通常，他們?yōu)榱藢崿F(xiàn)這一點，不得不在語法上做出一些稀奇古怪的事情，比如專門搞一些“聰明的”編譯器或者虛擬機……這種古怪的優(yōu)化行為使語言失去了原本簡單的性質(zhì)，更何況這種優(yōu)化往往只是針對處理器

當(dāng)你想要用c語言寫一些對運行速度要求嚴(yán)格的東西時，你可以很清楚的知道為什么他很快，這一點不因為你使用的編譯器或者虛擬機不同而改變。應(yīng)用程序中，GC（垃圾回收）的設(shè)置將會影響運行。而人機交互將會影響垃圾回收對于數(shù)據(jù)的處理。

c語言的代碼優(yōu)化直接而有效。即使你不這樣認為，在實際工作中也有大量的工具幫助你了解其中的緣故。相對來說，你根本沒有必要為此壯起膽子去嘗試學(xué)習(xí)什么虛擬機，什么“智能優(yōu)化編譯器”。當(dāng)你在使用cpu，內(nèi)存和IO分析器的時候，c語言絕對不會讓你對底層到底發(fā)生了什么感到困惑。以上所言，不論是從處理器的角度還是從內(nèi)存堆棧角度，都證明了c語言是速度之王。

更快的“編寫-運行-調(diào)試”周期

“編寫-運行-調(diào)試”這個開發(fā)周期對于程序員是十分重要的。如果這個周期足夠快，開發(fā)中的人機互動足夠多，那么你的任務(wù)就進行的足夠迅速。c具有主流靜態(tài)類型語言中最快速的人機交互性能。

因為“編寫-運行-調(diào)試”周期更多的是一種開發(fā)工具的使用原則而并不是一個語言的核心，所以他經(jīng)常被忽略。雖然如此，怎么宣揚這個循環(huán)對于開發(fā)速度的攻擊都不為過。悲催的是，這一循環(huán)已經(jīng)被很多變成語言遺忘了，他們反而去追求使用中的代碼的可讀性。所以，事實是，c仍然是最快的語言。

調(diào)試以及核心轉(zhuǎn)儲

對于任何你想將你的代碼移植過去的系統(tǒng)，你幾乎都可以發(fā)現(xiàn)一些c語言調(diào)試工具和核心轉(zhuǎn)儲工具。他們對于你能夠快速找到源代碼中的問題所在是非常重要的。當(dāng)然，他們也可能出現(xiàn)問題。

對于其他的編程語言來說，就沒有這么多的工具了。不論如何你都得承認，這些工具對于你c語言的變成起了十分重要的作用。假如要你寫一個c語言與其他語言的接口，或許你費了九牛二虎之力，卻做出了一個結(jié)構(gòu)十分復(fù)雜，運行十分脆弱，使用根本白瞎的廢物。

如果是純粹用c寫的程序，你可以察看調(diào)用堆棧，變量，參數(shù)，當(dāng)前線程……一切的內(nèi)存當(dāng)中最基礎(chǔ)的東西都毫發(fā)畢見。這真的很有效，尤其是當(dāng)你面對一個已經(jīng)宕機幾天的服務(wù)器進程而無計可施。而當(dāng)你面對一個用其他高級語言寫就的程序是……準(zhǔn)備受死吧……

從任何地方調(diào)用

C有一個標(biāo)準(zhǔn)化的應(yīng)用程序二進制接口（ABI）支持每個操作系統(tǒng)，語言和平臺的存在。它不需要運行或其他固有的開銷。這意味著你編寫的代碼在C不僅是有價值的，從C代碼的調(diào)用方，但對于每一個可以想象的包，在語言和環(huán)境中還是存在。

您可以使用獨立的可執(zhí)行文件，腳本語言，內(nèi)核代碼中，嵌入代碼的C代碼，作為一個DLL，甚至從SQL調(diào)用。這是用得上系統(tǒng)編程和可插拔庫。如果你想要寫的東西一旦有可用的最可能的環(huán)境和使用情況，C是唯一明智的選擇。

是的！它有瑕疵

在C語言中有許多”瑕疵“ 。它沒有邊界檢查,很容易發(fā)生內(nèi)存沖突,有懸空指針和內(nèi)存/資源泄漏,螺栓支持并發(fā)性,沒有模塊,沒有命名空間。錯誤處理可能相當(dāng)繁瑣和冗長。當(dāng)調(diào)用堆棧崩潰，或者攻擊性輸入操縱你的進程，很容易就產(chǎn)生一堆錯誤。

它的瑕疵是非常非常有名的,這是一種優(yōu)點。所有的語言和實現(xiàn)有陷阱和難題。C只是更坦率的告訴它。還有大量的靜態(tài)和運行時工具來幫你處理最常見的和危險的錯誤。世界上很多使用最廣泛和可靠的軟件是用C打造，這就是缺陷被夸大了的證據(jù)，這些瑕疵容易檢測和修復(fù)。

為了編寫couchbase，我們團隊大概花了2 + 人/月解決Erlang虛擬機的問題。我們在Erlang的編譯器上花費了大量的時間和精力，卻仍然不確定到底發(fā)生了什么，而結(jié)論是或許是我們的插件的c 語言代碼出了什么問題。我們想找出問題，然而卻找不到。最終我們確定這是Erlang的核心里面有一個條件矛盾錯誤。這是我們唯一的成果。而太多的語言抽象掉了太多的東西，這無疑增加了類似我們遇到的困難。

最初，出于性能原因，我們決定用c重寫couchbase的代碼，并且決定couchbase的幾個新的特性也用c來寫。令人驚異的是，顯然事實證明，c 語言提供了對于程序的良好控制能力，而我們因此更容易快速找出程序的問題并進行調(diào)試。長遠來看，c語言顯然具有良好的生產(chǎn)效率。

我總是告誡自己，我需要一個更加高效的可以替代c語言的東西。它只要可以修正程序里面那寫毛糙的細節(jié)然后解決問題就可以了。但是從事實來看，不論是從語法、從語義、從工具或者從“自頂至底”的開發(fā)方法來看，沒有什么可以值得我們?yōu)橹垢冻雠?。到現(xiàn)在為止，c語言毫無疑問的是最高效的語言，我認為短期內(nèi)這不會有任何改變。

你可以在twitter上“推”我一下，然后就可以了解我對編程的一些看法以及couchbase的開發(fā)進度了~