說說c, c++ 和 go

　　今天接觸到了Go語言, 請原諒我如今才接觸到Go, 以前聽雲風大神提及過, 但我總把它和易語言混淆了, 致使我沒有更早的瞭解到這個語言.

　　就在一年多前, 那個時候的我仍是對C++無比的熱愛, 認爲c++是作後臺服務器的不二選擇. 那個時候總認爲c 跟 c++是一家的, 因此我總愛標榜本身爲c/c++程序員.

　　C++雖然徹底兼容了C(這是優勢, 也是C++致命的缺陷), 可是C++跟C的設計思想能夠說是很不同的, 具體提及來能夠參見雲風關於C++和C的一些討論.

　　對C++的認識隨着本身作聚能推項目不斷加深, 我瞭解幾乎全部c++的特性, 但說實在的, 我能用上的特性真的很少. 我也試圖研究那些神通常的模板元編程, 但我實在是研究不下去, 由於我以爲這麼複雜的的實現, 只是爲了那麼一點點的效率, 值得嗎? 除了做者本身, 我估計沒幾我的能看懂他寫出來的模板代碼. 這對於維護簡直就是噩夢. boost, 是模板元的深度中毒者的傑做. c++的類庫支持仍是太少了, 因此當時我不得不借助於boost庫來達到不重複造輪子的目的. 正是由於模板元, 開始讓我意識到, 是否是c++的設計真的過於複雜了. 我曾經期待, 真的很是期待, C++能有一些改變, 至少不會像如今這樣複雜. 而c++ 11的出臺讓我對於c++委員會更加的失望.

　　雲風曾經也是個熱愛c++的人, 後來他義無反顧的迴歸到了c的懷抱, 由於他認爲c++的語言包袱太大了, 他還引用了linus炮轟c++的那篇文章來抒發本身心裏對c++的失望. 我幾年前就看過Linus大神的那篇著名的文章. 當時我不覺得然, 我認爲Linus我的偏見大過於理性分析, 雖然不少地方頗有道理, 好比說內存管理跟字符串處理不是程序的關鍵, 設計纔是關鍵. 當時我認爲, 若是不用c++, 還有其餘什麼選擇呢? 動態語言如python, lua, ruby, 咱們就不加入討論了, 由於動態語言跟靜態語言是有質的不一樣的. JAVA能夠算是一個候選者吧, 可是我沒有學習JAVA, 雲風也沒有, 我相信不少C++程序員也會和我同樣, 很難轉向JAVA.

　　說說本身爲何沒有選擇學習JAVA. 其實這帶有我的的偏見跟習慣. 就如同當年雲風對於JAVA嗜之以鼻同樣, 我對於這個連內存管理也須要由GC來幫忙的編程語言一直提不起太大的興趣, 當時認爲內存就應該由程序員徹底控制, 怎麼能讓GC摻和呢..並且java的安裝包(這是我最不能接受的)有100多M..並且JAVA畢竟太像C++了. 我以爲沒有太大的必要去學習一門跟C++功能相似的語言了. 因此...我就在c++的道路上越走越遠...

　　後來接觸的python, 被它給力的類庫秒殺, 實在是難以讓人拒絕使用. 因此通常的小東西我都是直接用python搞定的. 可是對於一些大型的項目, 我第一個想到的就是C++

　　其實我對c++太過複雜是有感受的, 只是, 我又不想去學習一門相似JAVA那樣的解釋性靜態語言....

　　我一直在尋找, 一直在尋找, C++的替代品.

　　這個替代品我曾經覺得是lua..可是看完lua, 仍是沒有知足我對編程語言的想象.

　　我心目中的編程語言應該是這樣的.

　　屬於C家族. 能夠去除一些C++中過於複雜的特性, 但具備C++和C的優勢(性能, 靜態語言), 開源, 能夠有更加好的名字空間管理(我實在受不了namespace), 有一個不錯的GC(自從玩了python, 我就對於gc好感大增.), 支持協程, 而不是多線程(我對多線程深惡痛絕).

　　嗯, 可能你們都看出來了, GO語言幾乎知足我對編程語言全部的想象.這篇文章證明了個人想象Go語言之父談Go：大道至簡

　　我想, 我應該很快會放棄用c++寫代碼了.

　　其實我並非討厭c++, 我以爲c++於我, 是一個窗口, 讓我經過它瞭解了更多的底層的知識, 讓我對計算機的理解更加的深入.對效率的把握更加的準確.而它複雜的語法也讓我對於其餘編程語言的上手都很快速, 由於沒有一個語言..能有C++那麼複雜..:(

　　或者純C, 或者go. 或許我會回到c++, 可是出於對C++標準委員會這些年作的事情, 實在是再也不敢抱有任何的但願.