本文內容摘自http://blog.csdn.net/turingbook/article/details/1775488
C++是一種糟糕的（horrible）語言。而且因為有大量不夠標准的程序員在使用而使情況更糟，以至於極容易產生徹頭徹尾的垃圾（total and utter crap）。老實說，選擇C就是為了把C++程序員踢出去。……我有這樣的結論，任何喜歡用C++而不是C開發項目的程序員可能都是我希望踢出去的人，免得他們來搞亂我參與的項目。C++會導致非常非常糟糕的設計選擇。你們這些C++程序員總是一上來就用語言的那些"漂亮的"庫特性比如STL、Boost和其他徹頭徹尾的垃圾，這可能對你們的程序有所"幫助"，但是卻會導致：
——當庫無法工作時無窮無盡的折磨（別跟我說什么STL尤其是Boost很穩定而且可移植性很好，那全是屁話，而且一點都不可笑）
——低效的抽象編程模型，可能在兩年之后你會注意到有些抽象效果不怎么樣，但是所有代碼已經依賴於圍繞它設計的‘漂亮’對象模型了，如果不重寫應用程序，就無法改正。
也就是說，使用優秀的、高效的、系統級的和可移植的C++的唯一方式，最終還是限於使用C本身具有的所有特性。項目限制只用C，意味着參與的人不會搗亂，也意味着會得到許多真正懂得底層問題，而不會折騰那些白痴"對象模型"垃圾的程序員。
所以，我很抱歉，但是對於Git這樣效率是主要目標的軟件，C++的所謂優點只是巨大的錯誤。而我們將看不到這一點的人排除在外卻成了一個巨大的附加優勢。
如果你想要用C++寫的版本控制系統，去玩Monotone吧。他們確實使用了"真格的數據庫"，使用了"漂亮的面向對象庫"、使用了"漂亮的C++抽象"。可是說老實話，所有這些對某些計算機專業人士而言富於吸引力的設計決定，其最終結果確是一堆可怕、難以維護的垃圾。
事實上，Git比其他軟件配置管理軟件都要好，而好的品味（taste）和C正是原因之一。說得更具體一些：
——簡單和清晰的核心數據結構， 非常精益（lean）且頗具雄心的代碼管理着它們，將”簡單勝於花哨”這一方法發揮到極致。
——有意識地不抽象數據結構和算法，因為它們恰恰是Git核心的全部要素（whole point）。
如果你想用更花哨的語言，C++絕對是最糟糕的選擇。如果想要真正的高級特性，那就選擇有垃圾回收或者好的系統集成的，而不是既缺乏C的簡約（sparseness）又缺乏C的直接而且沒有重要概念的高層 綁定（high-level bindings to important concepts）的東西。
一言以蔽之，C++正處在困境當中，它既無法幫助原型化或者簡單的GUI編程足夠簡化從而真正可用，又 不是C那樣積極地鼓勵你使用簡單和直接的語言構造的精益系統編程語言。
好的品味永遠不會過時。將C與匯編語言相提並論，恰恰說明你對自己所討論的問題缺乏起碼的概念（don't have a friggin idea）。"
字符串/內存管理根本無關緊要。還是去看看源代碼吧（我敢打賭你沒有看過）。這不是重要的部分，而且也不復雜。唯一真正重要的部分是設計。有些部分之所以是用 "原型化語言"編寫，恰恰是因為它們不是核心部分，而且會被C慢慢地替換掉。C++可沒有辦法替換shell腳本或者Perl代碼。而且C++也沒辦法讓真正核心的部分變得更好。
C在很多方面都遠遠優於C++（更優於C#），包括可移植性，還有接口和低層支持。
你當然可以用任何語言編寫糟糕的代碼。但是，有些語言，尤其是帶有一些心理（mental）包袱的語言本身就非常糟糕。你這樣的新手跑來指出一些絕對無關緊要的補丁特性（此處應該指C++對C的增強特性），用它們作為一種語言優越的論據（這些東西語言原作者都不喜歡），這一事實本身恰恰說明你滿腦子都是糊塗概念，應該好好醒悟一下了。
對於Git核心代碼真正重要的，是諸如這樣的事情：編寫自己的對象分配代碼，使內存占用盡可能小，從而能夠高效地記錄百萬對象的標志。這實際上是為樹形關系的多個對象編寫本質上非常優化的分析程序，因為這里沒有任何抽象。這絕對是在原始內存字節一級上的。
這些事情能夠用C之外的語言編寫嗎？當然可以。但是那些認為C++字符串處理這樣的高級特性很重要的人肯定是寫不出來的。
事實上，這正是C擅長的事情。不僅指語言本身，還包括一種必需的心態（mentality）。C最大的優點之一，就是它不會使你認為程序是什么高層的東西。正是后一種心態會使你明顯偏向其他語言，但實際上從Git的角度看來，所謂“高層”恰恰是錯誤的。