作者 | JOS VISSER
編譯 | 王瑞平
最近，大家總在吐槽Python：“雖然它是一種不錯的語言，但不適用于專業(yè)領(lǐng)域?！?/p>
圖片
數(shù)據(jù)顯示：Python依然排名第一，占比13.33%；C語言緊隨其后，排行第二，占比11.41%；C++位列第三，占比10.63%，與C語言差距為0.78%。
圖片
此外，Java和C#分別排在第四和第五位，占比分別為10.33%和7.04%。JavaScript在本月依然保持榜單第六位，占比為3.29%。
雖然Python如此受歡迎，但它能否持續(xù)流行依舊是一個重大問題，很多用戶普遍認為，如果持續(xù)使用將會使行業(yè)倒退好幾年。
1、局限：Python無法開發(fā)大型應用程序
Python對于開發(fā)大型應用程序不太友好，在工程化實踐中需要特殊的技術(shù)支持。
“我曾用Python編寫過大型應用程序很多年。由于Python入門非常簡單，在編寫大型應用程序時就像用樂高積木構(gòu)建核反應堆一樣?！痹髡咴谖恼轮行蜗蟮乇扔鞯?。
“但是，現(xiàn)在‘反應堆’已經(jīng)運行很久，輻射泄漏到處都有，我們需要到處‘貼新磚’讓‘反應堆’持續(xù)運轉(zhuǎn)?！?/p>
實際上，目前唯一能做的就是將“反應堆”封裝在混凝土中讓它冷卻下來，然后再用合適的建筑材料構(gòu)建出一個新的。
認為“Python無法開發(fā)大型應用程序”的網(wǎng)友認為它“不太友好”，在工程化實踐中需要特殊技術(shù)支持。
圖片
也有反對者認為：在大型項目中，與影響更大的其它因素相比，編程語言的語法、語義、范式等幾乎無關(guān)緊要。團隊經(jīng)驗和熟悉度、開發(fā)管理、流程、實踐、支持工具、文檔、語言生態(tài)系統(tǒng)、語言成熟度、管理支持等都會對項目結(jié)果產(chǎn)生更大的影響。
另外，從技術(shù)層面來講，質(zhì)疑Python無法開發(fā)大型編程語言只能反映提問者對相關(guān)開發(fā)缺乏了解。這些質(zhì)疑一是源于Python的動態(tài)類型特性，使類型推斷變得困難，對代碼的靜態(tài)檢查和重構(gòu)十分不利；二是由于Python代碼沒有編譯過程，因此缺少編譯時檢查錯誤機制。
關(guān)于動態(tài)類型特性質(zhì)疑，Python從3.3版本起就引入類型聲明，因此，只要遵循規(guī)范編寫代碼，類型推斷和代碼重構(gòu)就不是問題。
不久前，ChatGPT的問世也證明了Python可以寫出高性能、可擴展性強的大型分布式計算平臺—Ray。目前，這個平臺已匯聚超過1億的月活躍用戶。
“糟糕的應用程序架構(gòu)是絕大多數(shù)應用產(chǎn)生性能瓶頸的原因，而不應該由開發(fā)語言來背黑鍋?！庇行┰u論者這樣認為。
2、速度慢
誠然，Python與其它開發(fā)語言相比，在運行速度方面確實落后不少。究其根源，還是由于Python之父認為不需要過多關(guān)注Python的速度問題，認為它已經(jīng)足夠快了。
確實，對于99%以上的任務(wù)來說，Python的速度夠快，快到足以支撐早期Google和Dropbox。
自那時起，Python的速度又有了顯著提升，但開發(fā)者仍要求Python運行得更快。因為，無論人們已經(jīng)使用Python構(gòu)建出算力多么驚人的計算平臺，它的計算能力在很多場景下依然更慢。
3、功能差
當然，Python是一種靈活的和duck類型的語言：我們鍵入代碼、保存它，然后僅在運行時才能根據(jù)輸入的數(shù)據(jù)確定語句始終有效、有時有效還是根本不可能實現(xiàn)。
此外，你在用Python編寫程序時，只能部分控制進入該函數(shù)的數(shù)據(jù)，需要嚴格檢查所有輸入的數(shù)據(jù)。
更糟糕的是，Python的duck式輸入方式可能會引入“可怕”代碼，這會帶來麻煩。
4、錯誤百出
我在用Python編寫大型應用程序的這些年里，經(jīng)歷過一些可怕的事情；如果這些應用程序是用理性的、安全的語言編寫的，這些事就不會發(fā)生。
*在幾年前的一個例子中，我設(shè)法說服組織用Rust重寫系統(tǒng)，效果非常不錯！
實際上，我曾多次在社區(qū)中發(fā)布用Python編寫的大型應用程序新版本，結(jié)果卻立即被錯誤“吞噬”；這些錯誤都是由Python代碼異常導致的。
*Python的捍衛(wèi)者會說，這不是語言的缺陷，而是代碼審查和測試方法的缺陷。
*他們錯了！理論上，測試方法主要是查看每一行代碼并檢查每個輸入和場景，但實際上這并不可能！
好的編程語言的特點之一是：你不必檢查和測試內(nèi)存中每個相關(guān)位置的排列；如果必須詳盡地檢查和測試每個“a=b+c”，程序?qū)⒖赡苡肋h無法應用于實踐。
我會經(jīng)常查看Python函數(shù)，并想了解是否有人實際調(diào)用了它們以及攜帶了哪些參數(shù)。
我也經(jīng)常不得不“求助”代碼庫的全文搜索功能尋找調(diào)用位置；不幸的是，即便沒有輸出任何結(jié)果，當我刪除相應函數(shù)時，程序依然會崩潰；就算程序沒有立即崩潰，也無法判斷程序是否會在某種情況下崩潰。
5、分叉進程，耗盡內(nèi)存
用Python的另一個問題是內(nèi)存。我的筆記本電腦有10個CPU內(nèi)核，其中，Python應用程序大約占用1.2個。
這該怎么辦呢？幸運的是，我可以在Python中使用分叉工作進程的功能處理請求，確保所有核心都能正常使用。
不幸的是，分叉進程的操作很快就耗盡了內(nèi)存，所以我決定在處理完一定數(shù)量的請求后自行終止分叉，然后由Linux進行內(nèi)存管理。雖然這并不是Python本身的問題，但Python使內(nèi)存管理變得更加糟糕。
分叉工作進程還有另一個影響：Python使用引用計數(shù)法擊敗了寫時復制。為控制引用計數(shù)，保存只讀變量的內(nèi)存塊也被寫入，從而耗費了一定的內(nèi)存。
解決這個問題的有效方法是：讓編譯器對所有由主進程創(chuàng)建和由worker進程繼承的變量使用參考數(shù)值，而不必觸及到具有該參考數(shù)值的引用計數(shù)。
這是超級聰明的解決方案，但我認為應該沒這個必要。如果你需要破解編譯器才能讓Python為你所用，那這種語言又有什么用呢?
總之，Python使編寫可靠、易于維護和快速的代碼變得非常困難。
6、將Python替換成GO
當我對Python忍無可忍之時就會轉(zhuǎn)向Go，它使用起來幾乎與Python同樣容易、安全，還能快速構(gòu)建系統(tǒng)并生成高度優(yōu)化的二進制本機代碼文件。
雖然Go也并不是完美的，但是，如果你想可靠和快速地編寫代碼，并在代碼失控時可以調(diào)試和重構(gòu)，Go比Python好很多！
參考資料：
https://www.zhihu.com/question/321166662/answer/2937406779?utm_id=0
