為什麼 Dropbox 等大型服務使用 Python 作為主要語言，即使它的效率比其他編譯型語言低幾個數量級？
看到 @vczh 輪子哥聊到計算能力過剩的問題
現在前端的東西越寫越大，動態類型的弊端暴露的也就越多，不然就不會有那麼多人喜歡用TypeScript了。這跟性能仍然沒有關係。反正現在大家的計算能力都過剩，分散式的技術也已經成熟了好多年了，實在不行就加錢嘛，到了今天誰還管這個。
忍不住過來聊幾句。如果用戶感覺不到/不在乎，什麼語言、演算法都是浮雲，挑自己寫著爽的就好了。
幾十年前大家寫編輯器的時候，內存硬碟計算能力都不行，大家寫起來各種奇技淫巧，牛逼一點的就 Rope，不想寫的太痛苦就選擇 Gap Buffer ... 結果現在呢，大家都用 JavaScript 來實現的，UTF-16 的 String 用起來當然比 ArrayBuffer 爽的多了，當然內存也多一倍。數據結構就用 Line based Array 吧，不然優化 Rope 的時候還得手寫紅黑樹。反正一個兩萬行的代碼，你在最前面插入新的一行，Array Splice 花了 1ms 都不到。唯一一個有修為的 Bracket (CodeMirror) 用了 BTree，可是該倒閉還是倒閉啊。
機器性能過剩的情況下，大家寫的爽不爽很重要。當然如果有競爭對手跟你（在性能上）較真的時候，你就需要換個合適的語言、寫一點新人不太好維護的代碼了。好處也是明顯的，提升個幾十倍幾百倍。
現在語言快慢已經不是一個重點了，反正大家的機器都那麼牛逼。今天選擇一門語言，更多的還是看這門語言重構起來的難易程度。像Dropbox這樣的服務，開發起來需求十分純粹，是非常容易模塊化的，模塊之間的交互簡單到人類只要把文檔寫下來就可以不斷的開發下去，那麼選什麼語言都是差不多的。
難的是什麼呢？這其實也有很多，譬如說簡單點的，做一個資料庫。資料庫的數據結構那麼複雜，還要一個SQL的實現跟他緊密結合起來，無論你架構做的多牛逼，都無法避免的要在修改一點需求的時候動到幾乎所有的東西。
譬如說你原本的隔離模式運行了20年，然後突然要加入MVCC；或者說你新加入了兩個新的索引類型；或者說你把disk based升級成了in memory，是不是
- parser也要改
- AST也要改
- execution plan格式也要改
- execution plan的優化演算法也要改（升級到SSD還能勉強該改參數，到了in memory之後甚至你都要重頭做一個storage的格式和配套的優化策略）
- plan的每一步實現也要改
雖然這些需求變更看起來都互相很獨立，但實際上並不是這麼回事。這個時候人類光靠文檔就沒辦法繼續開發下去了，所以還需要靜態類型的輔助，畢竟文檔是會滯後的，但是編譯器不會。當然靜態類型不能解決所有問題，如果C++到了你手裡就變成了一大堆void*，那也白搭。
那麼如何最大限度地發揮靜態類型語言的優勢呢？我們需要學習type rich programming的思想。
類似的事情還有Office、遊戲等等用戶需求超級複雜，而且每個人的20%都不一樣的軟體，只要你想賣出去，就無法做任何取捨。這也可以舉出很多例子，譬如說文檔編輯程序突然想要支持蒙古文，文字終於變成有豎排還有注音的了，之前你的排版演算法要是設計的爛還得重頭做一個，配套的渲染優化演算法也要再做一個。遊戲開發了好幾年，突然要加入競技場模式，還要加入副本，帶來的結果基本不亞於重寫。
Dropbox好就好在，他的需求變更永遠都不會這麼劇烈。
現在前端的東西越寫越大，動態類型的弊端暴露的也就越多，不然就不會有那麼多人喜歡用TypeScript了。這跟性能仍然沒有關係。反正現在大家的計算能力都過剩，分散式的技術也已經成熟了好多年了，實在不行就加錢嘛，到了今天誰還管這個。以2017年的軟體工程的經驗，想要寫出一個加錢不能提高性能的程序，已經不是那麼容易的事情了。
任何「XXX語言太慢」的觀念都是以偏概全。
應用程序分很多種，CPU bound, I/O bound, Memory bound, 等等。如果你的程序屬於I/O bound，即使你把整個程序換成手工優化過的C，速度不會有本質提升。
對於Dropbox來說，其業務邏輯不複雜，性能瓶頸顯然在I/O. 除了我估計判重時的 SHA 運算量比較大，但 CPython 的一大優勢便是很容易使用 C 寫模塊，找到 hot spot 後再用 C 來寫也不遲。"Premature optimization is the root of all evil."
既然如此，使用一種性能稍差但易讀易寫、生態系統完善、跨平台、迭代迅速的語言便是順理成章的了。
更何況，Guido, Python 的作者，已經被 Dropbox 挖走了。
我2013年時寫一個音頻識別引擎，性能優化是很重要的，直接決定了我每天可以跑多少輪迭代優化識別效果。實現方面用的是Python，庫用了Numpy等。每次處理的數據量很小，就十幾個MB，但需要內部做密集CPU計算。
後來我就發現2010年的macbook pro跑單核，比2013年的e5還快15%左右。我就開始思考人生了，前者是民用的移動版CPU，還略老；後者是商用伺服器CPU，還新了3年。
後來就此事問了一些運維的朋友，才明白，伺服器CPU以及整個伺服器硬體系統，優化等等方向是更大的IO，而不是單核計算性能。在現代，絕大多數應用的性能瓶頸最終都卡在了IO上，而不是跑滿CPU。而IO的速度足夠慢，用什麼編程語言已經沒什麼區別了。那麼此時選個寫代碼更方便的語言就凸現出了優勢。
IO是個廣義概念，包括網路、磁碟、內存等等。網路的速度大家都懂，伺服器上無非是多加幾個Gbps的網口來處理。磁碟的話，機械硬碟每秒十幾次的磁頭定位速度，使得任何隨機讀寫就是證明設計者腦殘而沒有做連續讀寫優化。內存的帶寬也是個大問題，頻率乘位寬就知道也是比預期慢得多。
另一個角度講，如果一個軟體系統能把CPU先跑滿，說明軟體優化做的不夠，很多計算可以利用緩存來提速的，直到緩存速度受限於內存帶寬為止。
Dropbox這種存儲服務，瓶頸幾乎一定在IO上吧？
Python的確比compiled languages(編譯型語言）慢幾個數量級，但這隻與受CPU限制的應用有關。
Dropbox主要受磁碟和網路約束。因此，使用編譯型語言並不會明顯加快Dropbox，因為大部分時間都花在讀寫數據而不是計算上。解釋型語言的優點在於開發速度，這也是為什麼大多數網站都用解釋型語言作開發。當這些缺點被邊緣化時，程序員從這些優點上受益。
參考資料：
William
Ting"s answer to Python (programming language): How can some really
large services (like Dropbox) afford to use Python as a primary
language, if it"s one to two orders of magnitude slower than other,
compiled languages?
解釋型語音的優點就在於開發速度快，缺點是執行效率低。Dropbox本身可能的瓶頸只是在I/O，對效率其實是無所謂的
Python等語音越來越受歡迎，開發簡單門檻低是非常重要的原因。在我們那個年代，人人都用C這樣的，你試試用C編個應用試試看。我想如果現在還用C的話，有一大半程序員都得轉行
現在大型系統很少用單純一種語言寫出來。。每種語言有每種語言的特色和適用環境。
企業會根據具體的使用環境（IO密集還是計算密集、開發效率等）來為不同的組件選擇不同的語言。
對於那些對效率要求極高，但很少改動的地方用編譯型語言。對開發效率要求極高，三天兩頭就要加入新功能的組件來說，上線所需的「時間成本」要比為了提升速度所需的「硬體投入」要值錢得多。
使用解釋型語言的主要環境就是在「以（硬體佔地）空間換（開發）時間」的一種經濟的行為。。
Dropbox 那種能幾年不上新功能的產品，確實可以不再用 Python 了。這不用 Go 重寫也搞得起嗎？
Youtube 那種還要幫 Google 賺市值的產品，還在瘋狂的迭代，都明智的選擇擼 Grumpy。
所以答案還在看工程師閑不閑，不閑別瞎換就是對的。熱乎乎的，剛出爐不久：
Instagram 在 PyCon 2017 的演講摘要
http://www.zlovezl.cn/articles/instagram-pycon-2017/
https://www.youtube.com/watch?v=66XoCk79kjMfeature=youtu.be
「如今，Instagram 的總註冊用戶達到 30 億，月活用戶超過 7 億 （作為對比，微信最新披露的月活躍用戶為 9.38 億）。而令人吃驚的是，這麼高的訪問量背後，竟完全是由以速度慢著稱的 Python + Django 支撐。」
Instagram 蠻拼的，Python 3 大法好！「你」會問這樣的問題在於：
1，沒有掌握經濟學基礎常識
2，不具備運用邏輯思考問題的能力
先說基礎常識
任何東西都是有價的，追求運行效率會付出開發成本
重要的是在成本和收益之間找到平衡點而不是學人家高喊什麼『用愛發電』『生命無價』『效率、質量永遠是第一位的』（你很可能甚至都不知道什麼是效率）
簡單說來就是『魚我所欲也』
再說邏輯思考能力
題目的論據是「Python 的效率比其他編譯型語言低幾個數量級所以本不應該用的」
那麼這個業務具體什麼地方被卡殼了?
到底低了幾個數量級?
運行效率具體在什麼地方會有什麼樣的差異?
為了解決這個差異要付出多少代價?
影響業務的因素有哪些? 是否只包含語言運行效率?
...
背後的問題多著呢, 不是一句含糊不清的「定論」就能夠掩蓋過去的
如果你面對問題只是用這種似是而非感覺糊弄一下就好的態度, 那也就告別解決問題了
想要更好更快地分析、解決問題, 就應該學會用邏輯來思考
所以來看 guabuy 的推薦提高一下邏輯思考問題的能力吧
一套 6 本京東打折菜 130
簡直了...
以大部分人的業務瓶頸和代碼邏輯水平，性能過低的鍋還輪不到你們甩到編程語言的頭上
運行效率這個問題，只有在它成為問題的時候才是問題，在它不成為問題的時候，它就不是問題。
如果在效率這個問題不成為問題的時候還去糾結這個問題，那我們只能用彙編了。樓上說dropbox卡在io上的，都用過分散式環境嗎？
在分散式系統里，cpu和io並不一定是1：1的配比，你完全可以搭成一個cpu帶13塊盤，或者兩個cpu帶48塊盤的配比。無論io多大都不會是瓶頸（隨機尋道時間的問題可以通過把熱數據轉移到ssd上來解決）。
Dropbox用Python和語言性能沒有關係。
而是作者需要python的開發效率（學C++，QT是不現實的），又能編譯成原生桌面App。Python配合WxPython和PyObj這些庫，可以相對比較低成本地一套代碼得到跨平台桌面應用。
現在讓你用解釋性語言去寫一個跨平台的桌面應用（不是electron這樣的瀏覽器殼子），你會發現Python是唯一比較靠譜的選擇。
Dropbox tech stack
像 Dropbox 這樣從 Python 轉到 Go 語言是不是新的趨勢？
語言的執行效率當然重要了，特別是產品「穩定」後，需要再提升競爭力和用戶體驗的時候。
如果本就熟悉高效率語言，那麼建議一開始就使用它，免得後面花時間重構，這是浪費投資人的錢和消磨用戶的時間。
關鍵是IO速度慢 也就顯不出python慢了
大型服務使用 Python 作為主要語言的，我知道比較有名的是 Dropbox，YouTube，Quora 和知乎。其實分析Dropbox和YouTube為啥使用 Python意義並不大，因為Dropbox的文件同步和 YouTube 的在線視頻這種核心的功能，我相信都不是用 Python 來完成的。
反而分析 Quora 和知乎為什麼採用 Python 作為主要語言，相對更加準確一些，Quora為什麼使用Python，我引用Quora創始人Adam D"Angelo和Charlie Cheever在Quora上的現身說法，知乎為什麼使用Python，還請知乎的大牛們現身說法一下。
Adam 在回答中提到，他當初從 Facebook 離職創辦 Quora，首先就排除了 PHP，因為作為 Facebook 前 CTO 的他深知PHP 所帶來的痛苦；他也考慮過C#，Java，甚至小眾的Scala，OCaml 和Haskell，排除C#是不想受限於微軟的協議棧，Java 需要的開發周期更長，同時找到熟手較難。最後選擇 Python 的原因其實很簡單：Adam和另一個創始人Charlie對於 Python 都比較熟悉！
從後面多年的使用情況來看，Adam非常慶幸當初自己的選擇：所有的員工都很高興使用 Python，不管以前的主要語言是什麼；Tornado等框架的推出，讓更新等實時服務有了好的去處；PyPy可能在不久的將來讓 Python 性能有一次大的提升，在這個理想實現之前，Quora性能敏感的後端代碼都是使用C++編寫的。Charlie也補充說Django, Pylons等好的框架讓他們獲益頗多，Python 和 Javascript 的數據結構非常和諧，以及郵件服務，任務隊列等優秀的第三方庫。
引用出處：Quora Infrastructure: Why did Quora choose Python for its development?
網盤是以IO為主的，所以，用Python可能出現這樣的情況：
CPU 80% RAM 75% IO 100%
如果使用C重新寫一遍的確能省點內存和CPU：
CPU 60% RAM 65% IO 100%
我寧可用這麼一點計算能力換一個開發快捷。
現在誰還沒事一個語言寫到黑啊，需要什麼上什麼，大部分性能瓶頸的底層都是C++，然而上層還是要用python scala包起來，為啥？好用啊，邏輯好寫，代碼優美，特別小細節上新語言強大無比。這些query處理層面的東西，額外開銷相對於底層真正的性能開銷來說可有可無，根本成不了性能的瓶頸。
現在進程間通信或者分散式的情況下rpc開銷也不會很大。開發足夠穩定bug足夠少迭代足夠快才是王道。推薦閱讀：
※互聯網分享與版權保護相矛盾嗎？如何協調矛盾呢？
※為什麼香港的 IT 行業平均薪酬較低？
※高級運營和普通運營有哪些區別？
※你電腦上跑著哪些好玩腳本？