看來作者也是KSO輕辦公/企業快盤團隊的壹員。作為“從零開始”快迪的工程師之壹(肖驍兄弟總是告訴我，他們改變了我留下的bug)，這只是碰巧。
Python/Go雙修(霧其實是銹黨)，其實壹開始我是拒絕的，duang duang duang，所以隨便寫壹點。
首先，作者說Python是壹種動態語言。
Python是壹種動態語言，而不是強類型系統。對於壹個變量，有時候我們根本不知道它是什麽類型，然後可能會出現int+string之類的運行時錯誤。
在python中，可以允許出現同名的函數，後壹個函數會覆蓋前壹個函數，這曾經造成了我們系統的嚴重錯誤。
其實如果是靜態檢查的話，pylint和pyflakes都可以做到，雖然用go做不到。
那種靜態編譯語言比不過，但也夠了。如果沒記錯的話，阿童要求全組做壹個靜態檢查再提交。我覺得這種問題應該更多的靠人員素質來避免，畢竟洋蔥。
我還說，自己寫的代碼要多回頭看，看能不能重構，做得更好。不是說懶不好，而是Python可以從中得出。
動態特性太靈活，Python:怪我？
另外，函數作為第壹個對象，是Python中的壹個特性，Go完全沒有必要寫壹個mock。
其實這壹直是很多人吐槽python的地方，但是妳想想，python最初是為了解決什麽問題而開發的？我們堅持把它應用到高性能服務器的開發中，其實對it來說有點難。
如果沒記錯的話，無論是輕office還是快盤，我對IO的重視程度都超過了CPU，最耗時的是塊加密，我在的時候用Java寫的。另外，高性能服務器選擇Go，也是被濫用的，各種GC都小心翼翼的避開。在大多數極端情況下，pypy的性能是足夠的，我不認為這是壹個充分條件。
Python的GIL使得真正的多線程化成為不可能，人們可能會說我不能只使用多個進程。但是，如果某些計算需要涉及多進程交互，那麽進程間的通信開銷也必須考慮。
事實上，Python有可以繞過這個GIL的宏，但是設計良好的架構實際上是可以避免的。我將談論異步部分。
在無狀態分布式處理中使用多個進程是很方便的。比如在處理http請求的時候，我們只是在nginx後面掛載了200多個django服務器來處理http，但是這麽多的進程自然導致機器整體負載很高。
但是即使我們使用多個django進程來處理http請求，python仍然無法處理壹些超大型的請求。所以我們用openresty來實現lua的高頻http請求。但這就導致了兩種開發語言的使用，有些邏輯要寫兩種不同的代碼。
如果推測正確，妳還在用五年前寫的網關嗎？那是基於姜戈路線
的流量分配層？四年前我離職的時候用Flask+Gevent Demo做了壹個小範圍的測試，無論是性能還是負載都比同步模型的django要好。
有優勢。如果又是姜戈，
在這種情況下，我只能說很可惜。畢竟金山新員工大賽的第壹張牌是我和幾個朋友寫的實時同步在線文檔編輯系統，用的就是這個技術。
所以這是工程問題，不是語言問題。Python給妳提供了那麽多工具，妳還要選壹個傳統的，舊時尚的，Python:怪我？
Django的網絡是同步阻塞的，也就是說，如果我們需要訪問壹個外部服務，在等待結果返回的同時，django無法處理任何其他邏輯(當然多線程除外)。如果訪問外部服務需要很長時間，就意味著我們的整個服務將在很長壹段時間內完全不可用。
為了解決這個問題，我們只能不斷的開放django進程，同時需要保證所有的服務都能快速的處理響應，但是想想其實是壹件很不靠譜的事情。
同步模式也不是不可以，因為開銷足夠低，在很多業務場景下都會取得比較好的效果，比如豆瓣。同步模式的最大問題是IO密集型業務的等待時間足夠長。這時候需要的不是改變語言，而是提醒妳架構是否需要改變。
雖然tornado是異步的，但是python的mysql庫並不支持異步，這意味著如果我們在tornado中訪問數據庫，仍然可能會面臨由於數據庫問題導致整個服務不可用的情況。
Tornado確實有這個問題，但是gevent已經解決了。我曾經在node.js中為node回答過壹個問題，
壹般來說，只有壹個異步模型可以選擇，Python的選擇太多了。再說pypy+龍卷風+redis。
妳可以隨意濫用各種長連接場景，比如我為我們工廠寫的壹個推送服務。
其實異步模型最大的問題在於代碼邏輯的碎片化，因為是由事件觸發的，所以我們都是通過回調來處理，所以經常是這樣的情況，代碼裏做了壹件事，傳了壹個回調，回調裏又傳了壹個回調，結果就是整個代碼邏輯非常混亂。
這真的不是。如果沒有ES6的JavaScript，可能會有回調地獄，但這是Python！計算機編程語言
左值綁定早就實現了。唉，yield的姿態比壹些天天吹的語言高多了。當然，我說的是完整版的Python3 yield。即使它是不完整的。
Python 2 yield對於異步表達式求值也完全足夠，tornado的gen.coroutine
同步寫是異步的，這在Python公司早就流行了。這是工程問題，不是語言問題。當然，這要怪Python。蟒蛇:怪我？
Python沒有本地協程支持。雖然可以通過gevent、greenlet等補丁的方式支持協程，但是python的源代碼已經改了。另外python的yield也可以用於簡單的協同仿真，但畢竟不能跨棧，局限性很大。不知道3.x的版本有沒有改進？
Gevent和Greenlet都沒有修改Python源代碼。事實上，這款產品已經成為Py2協程的標配。加上豆瓣的開源產品greenify，基本上所有庫都可以平滑異步，包括MySQL等C級庫。自從用了這個技術，豆瓣的Python dev就各種爽。
我第壹次用python開發項目的時候，沒有成功安裝項目需要的包。成功安裝mysql庫花了很長時間。後來是壹個同事把他的整個python目錄打包給我用，讓我正常運行項目。換句話說，現在有docker是壹件多麽幸福的事。
部署python服務時，我們需要在服務器上安裝壹堆包，非常麻煩。雖然我們可以通過puppet、salt等自動化工具解決部署問題，但是用靜態編譯語言拋出壹個二進制文件要方便得多。
正好我在開發壹個基於docker的平臺，docker真的不是用來部署的。第壹，Python有virtualenv。
其實Python相對於包管理和包隔離來說，比Go高也不知道高在哪裏。Python和Git談笑風生的時候，Go的dev。
科學家們不得不考慮我如何才能讓導入包穩定在壹個版本中(當然現在也有很多第三方的解決方案)。Virtualenv+Pip完全可以實現。
Python部署是自動化的，所以我認為這個問題是壹個工具鏈選擇問題。畢竟他是十幾年的老怪物了，蟒蛇。
我以前什麽都沒見過。妳可以選擇各種打包工具，妳堅持Python部署不方便。蟒蛇:怪我？
Python非常靈活簡單，以前寫幾十行C代碼才能解決的功能，可能壹行python代碼就能解決。但是太簡單了，反而引出很多。
學生無法深入思考代碼，仔細考慮整個架構。有需求，敲擊鍵盤，實現速度。結果代碼越來越亂，最終導致整個項目代碼。
失去控制。
曾經在知乎有個帖子問Python會不會降低程序員的編程能力。
我只能說確實有關系。妳不去想深層次的東西，怪語言不行，這是不合理的。那麽，goroutine在Go，one with socket中是如何實現的呢？
戈羅廷
妳能做多少記憶？妳想過嗎？任何語言都有自己的優缺點，需要執行者自己去判斷。單純的思考，不深入的思考，是有問題的。另外，我覺得代碼很混亂。
盡管如此，工程控制是不夠的。豆瓣有壹個Python實現，超過10W行。雖然並不完美，但大體達到了不亂的目的。
還有，C寫幾十行Python來解決這個問題，這絕對是壹大特色，生產力，人員配備，招人成本。從工程的角度來說，Python是這壹塊的加分項，並不是每個項目都要求極致的並發和效率，做項目往往需要二選壹。
雖然java和php是最好的編程語言(大家都這麽爭鳴)，但我更喜歡更簡單的語言。和開放，雖然性
可以很強硬，但是lua還是動態語言，也會遇到前面提到的動態語言的壹些問題。最後，前金山許世偉用的是go，前快盤架構師洋蔥也用的是go，我們自然選擇了它。
去吧.
Openresty用的是lua。如果從動態語言的角度來看，真的不是。頂多是更簡單的c，許世偉走的時候，大部分都是
CPP，洋蔥目前，我不知道他用什麽來寫他的業務，但他肯定沒有語言傾向。當年不管是leo還是ufa，壹個用Python，壹個用Python。
Java，他總是從工程實際出發選擇用什麽樣的語言。
Error，嗯，有語言潔癖的同學可能真的受不了go的語法，尤其是最後約定的返回值是error的時候。
這其實是圍棋風格。無論是go fmt還是錯誤風格，go其實都是想把不同工程師之間的風格問題抹平。不要為縮進和括號位置浪費時間。這個方法還不錯，但是個人感覺不如rust的返回值處理友好。
Gc，java的GC已經發展了20年，離go也就那麽壹點點時間，GC肯定還不完善。所以還是不能隨意寫代碼，不然gc可能會在大請求量下卡在整個服務裏。所以有時候，對象池要用，內存池也要用。雖然代碼有點醜，但至少性能是提升的。
1.4開頭，go是100%準確gc。另外，說到卡頓，完全和妳如何使用對象有關。完全可以內聯，絕大多數場景不引用，所以GC的影響力會最低。我真的想用遊泳池...我只能說為什麽不選Java。
天然的並行支持，因為有了goroutine和channel，用go寫分布式應用和並發程序變得異常容易。沒有痛苦的回調導致的代碼邏輯的碎片化，代碼邏輯是有順序的。
這是有代價的。goroutine的內存消耗計算(當然1.3或者1.4有了很大的提升，最小內存限制消失了)，通道。
跨線程帶來的性能損失(跨線程鎖)，goroutine的控制力幾乎為零。
等等。總之，不是什麽殺手級的功能。每個人都有。有點方便，但也有自己的缺點。比如我們用go，經常傷害spawn。
Goroutine優雅地關閉，但有時會使事情變得復雜。
性能方面，go的性能可能趕不上c、c++和openresty，但確實很強悍。在我們的項目中，現在壹個go進程部署在單臺機器上，完全有能力做之前200個python進程做的事情，CPU和MEM占用更少。
我不精確的測量表明，gevent+py2可以實現30%~40%相同邏輯的go實現，pypy+tornado可以實現。
80%~90%，混合壹些計算和連接處理。主要看業務場景，純CPU綁定當然是go，純io綁定。
用c也沒關系。
運維部署，直接編譯成二進制，扔到服務器上就行了，比python需要裝壹堆環境簡單多了。當然，如果有cgo，我們也需要拋出相應的動態庫。
根據glibc所在的主機版本，我們現在有兩套編譯環境。看似部署簡單，編制就要命了。另外，磁盤雖然便宜，但是這幾行代碼只有幾米，集群的同步部署需要時間，有些情況下真的會出錯。
開發效率，雖然go是靜態語言，但個人感覺開發效率真的很高，直觀上堪比python。對我個人來說，最好的
比如我用go快速開發了很多開源組件，比如ledisdb，go-mysql，這些初始版本都是在很短的時間內完成的。為了我們的項目
說起來，我們還用go用壹個月重構了第壹個版本，發布了。