C++
C++ 在 2011 年其實風頭甚勁，C++2011 標準出臺，gcc/msvc/clang 都很快速地支持了許多新特性，新興的移動設備的性能較差，更是 C++ 的新舞臺，在這個時候唱衰 C++，壓力很大。我使用 C++ 年頭不少，但除了在校的時候寫過兩個小遊戲參加過兩個比賽（分別是面向社會和麪向大學生的）弄些證書好找工作以外，在工作中只用過大概不到一年半，做《斬魂》（http://zh.163.com）的早期版本，寫了服務器端的幾條進程和客戶端的 GameAI 部分。經驗少，而且寫得不好，所以基本上有人在 weibo 上問我 C++ 的問題，我都是轉發給 @bnu_chenshuo 和 @miloyip 等真正的行家去回答的。所以實際上今天寫這一篇，我底氣很是不足，但是朋友們給前兩篇很大面子，弄得我騎虎難下，只好硬着頭皮寫了。
前文提到 C++ 的新標準，很有必要提一下標準化對 C++ 的影響。首先我們要肯定標準定製對 C++ 的積極作用，但標準化過程中的超長流程，一次次將 C++ 推向深淵。C++ 的第一個標準是 1998 年的 ISO/IEC 14882:1998，距離整個 90 年代最流行的 C++ 程序庫 MFC（Microsoft Foundation Class Library）的第一個版本發行時間已經整整 6 年。1998 年，MFC 版本號爲 6.0，與其一起發佈的 Visual C++ 6.0 佔有了巨大的市場。因爲 MFC 發佈得標準制定的時間早，所以 MFC 內部實現了許多後來標準庫裏也有的組件，比如各種數據結構容器。VC6 的市場佔有率讓 windows 平臺下開發的許多 C++ 程序員甚至不知道有 STL，同時也無視 C++98 標準，從更兼容標準的 VC2002/2003 的市場佔有率就可以看出來，直到今天，我知道國內不少公司還是隻用 VC6 的。
其實在 90 年代，計算機的運算能力有限，市場上非常需要一款性能較高、抽象較強的編程語言，C++ 獲得了成功，但它標準化的時間過長，造成各種編譯器有各自互不兼容的“方言”，成了它的第一個軟肋。第一個瞄準這個軟肋的就是 java，java 在 1995 年推出，雖然性能稍遜，但它有更高的抽象能力、也更安全，並且更容易跨平臺，所以迅速獲得了成功；第二個瞄準這個軟肋的是 C#，微軟不能推動 C++ 發展，又不願 C++ 的市場被 java 鯨吞，於是在 2001 年推出了 C#，經過 10 年的發展和微軟大量的金錢推廣，C# 已經成功獲得了它應有的江湖地位。
雖然 java/c# 都不是善類，但 C++ 在 21 世紀的第一個十年裏仍然地位穩固，這是因爲 Linux 和 MacOS X 大獲成功，在這兩個平臺上 C++ 都是非常有競爭力的編程語言，C++ 自然水漲船高。但隨着 web2.0 和 web app 概念的興起，以及 CPU 的主頻進一步提升，服務器端編程語言漸漸地對執行效率不再敏感，而是更在意程序員的開發效率，衆多的腳本語言開始蠶食 C++ 的市場份額，從早期的 perl 到後期的 python/php/ruby，在 2005 年以後，C++/java/C# 等靜態類型的編譯型語言的市場份額都下降了，新興的貴族是動態語言。面對動態語言在開發效率上的強勁挑戰，C++ 社區除了在 2003 年對 C++98 做了小小的 patch，基本上睡着了，完全沒有應對之策，哦不，連應用的姿態都沒有。
進入 21 世紀的第二個十年，市場又發生了變化，雲計算越走越近，也許我們中的大部分人今天還可以說只聞其聲不見其形，但 The Data Center Is the Computer 這句話大家應該覺得很務實：完成一個用戶操作，在服務器端的進程間通信次數前所未有地多。在這個十年，我們需要這樣的編程語言：
1、能充分利用現代 CPU 的計算能力，不僅僅是多個核心，更是巨大的 L1/L2/L3 Cache、超線程等；
2、能夠大量減小異步 I/O 的性能提升的同時帶來的副作用：異步編程的複雜性以及對可維護性的傷害；
兩句話其實也可以壓縮爲一句：需要有更好的併發模型的語言。一開始大家都在已有的編程語言中尋找，然後找到了 erlang，實踐證明 erlang 自有其侷限，所以 google go/scala/rust 等新語言如同雨後春筍般撥地而出。C++2011 標準努力降低 C++ 的編程難度，並提供了線程庫以支持現代 CPU，如果在 2005 年，這個標準絕對有競爭力，但在今天，它只能成爲新的編程語言的墊腳石。正如 IE 最大的用處是用來下載其它瀏覽器，不久之後，也許會流行新的冷笑話：C++ 最大的用處就是用來實現其它編程語言。
市場一直在尋找一門中間的高級語言，它上承 C 語言和彙編語言，下啓腳本語言。C++ 最先搶佔了高地，並在與 java/c# 的爭鬥中不落下風，但新的十年，它的對手又增加了 google go/scala/rust 等新銳，並且新的標準不可能在兩三年內再次出臺，兩三年內新銳成長起來後，留給它的位置就不多了。
上文討論的基本上都是服務器編程，有必要再來看一下桌面和移動設備領域。首先看桌面軟件，rust 是 mozilla 基金會開發系統程序語言的，它的定位是部分取代 C++ 開發 firefox 的瀏覽器，所以 rust 會進入桌面開發，google go 肯定會順道啃一口。移動設備方面，主要是 android、ios 和 windows phone，隨着移動設備性能增強，編譯型語言加腳本的模式就會佔大頭，編譯型語言方面主要是 C++ 和 Objective-C 在競爭，C++ 會佔上風（但需求量遠遠小於腳本，從 lua 在 2011 年的增長速度可以印證），但是誰知道 rust 之類的會不會進入移動設備呢，畢竟移動設備的 CPU 核心也越來越多了呀，C++ 還是前景堪憂。
回首 C++ 的 30 年，展望它的未來，總結起來可能就是：標準化流程拖死人了。如果不是 15 年不能標準化，java/c# 的攪局可能不會出現；如果在 2005 年能夠應對動態語言……如果雲時代有更好的併發模型……
題外話：java/c# 不會有 C++ 的問題，因爲它們有自己的平臺，有巨大的財富支撐。特別是平臺的作用非常巨大，你可以想像一下如果 Adobe 有自己的瀏覽器或手機操作系統 ActionScript/MXML 會不會是今天的境地；也可以想像一下 google go 的飛速發展動力是什麼。
兩點解釋
1、我覺得有必要解釋“不宜進入”一下這四個字，我想要表達的意思就是如果你現在不是這三個技術點的專家，並且手上沒有使用這三個技術點的項目，進入這三個技術點僅爲技術儲備，那麼就“不宜進入”。另外我不是說用了這三個技術點的項目就死，學了這三個技術點的人就找不到工作，或者這三個技術點明天或明年就 game over，渣都沒得剩，不是這樣的意思，它們還會存在很長一段時間。本文不是叫專家自廢武功，也不是叫已經做好技術造型的項目趕緊兒換技術，舉例說，如果你選擇了用 java 做服務器端，flash 做客戶端開發一個 webgame，那你最好玩命兒地把 ActionScript/MXML 和 java 多線程編程（及異步 I/O）給鑽透，不然可能隨時掉陷阱裏。
2、新年新氣象，工作和家庭都有很重要的事情壓在肩上，大家的評論我不逐條回覆了，我會在一兩個星期後再統一寫一篇《2012 不宜進入的三個技術點（Q&A）》統一回答，還請見諒。
