[[205208]]

最近我寫了一篇關(guān)于我為什么不擔(dān)心Python流失用戶的文章。幾分鐘之后有人問(wèn)我Python的用法(usage)，而這篇文章沒(méi)有提及，但卻是一個(gè)讓人深思的問(wèn)題。我們看到，使用Python的用戶很可能在未來(lái)保持高位，但是Python是否會(huì)被用到盡可能多的項(xiàng)目中是不能保證的;用戶(users)數(shù)目很多而且穩(wěn)定，但是項(xiàng)目中Python的用處(use)并不確定。

這篇文章的用意是幫助表明Python仍然對(duì)大多數(shù)軟件項(xiàng)目是切實(shí)可行的。我不擔(dān)心把Python推銷給反對(duì)其他動(dòng)態(tài)語(yǔ)言(如Ruby)的人，因?yàn)槲艺J(rèn)為這些爭(zhēng)論與個(gè)人喜好有關(guān)。這篇文章是講給那些推銷靜態(tài)類型語(yǔ)言的人。具體上，這篇文章是針對(duì)Go的，但也可以是其他任何靜態(tài)類型語(yǔ)言。

“為什么Go?”，你可能會(huì)問(wèn)。因?yàn)镚o實(shí)際上在獲取Python的用戶。當(dāng)2003到2005年間Python的增長(zhǎng)曲線是個(gè)曲棍球棒時(shí)，Python還不是被推下山巔的王者，而是個(gè)弱者。傳統(tǒng)上，Python從Java之類的語(yǔ)言陣營(yíng)中獲得用戶，并且留住了他們(我不想談C++用戶，因?yàn)橥ǔＫ麄冇袊?yán)格的性能需求，需要一個(gè)系統(tǒng)語(yǔ)言，或者是性能成癮者，并且需要好好恢復(fù))。但是Go的情況不太一樣。如今Python是使用最多的語(yǔ)言之一，而不再是弱者了。一旦在靜態(tài)類型語(yǔ)言社區(qū)中出現(xiàn)一門語(yǔ)言，它的生產(chǎn)效率/性能的取舍相當(dāng)好，那便足以說(shuō)服一些Python的程序員選擇Go而不再是Python了。

如今的Go

首先我應(yīng)該說(shuō)，Go是目前我第二喜歡的語(yǔ)言。如果今天我要啟動(dòng)一個(gè)項(xiàng)目，但不能說(shuō)服人們使用Python，那我會(huì)提議使用Go。不要誤解我在本文中說(shuō)Go是門不好的語(yǔ)言。這篇文章的要點(diǎn)是說(shuō)服其他人，Python是生產(chǎn)率/性能取舍游戲中Go之外切實(shí)可行的替代方案，而不是表達(dá)Go是門不好的語(yǔ)言。認(rèn)為這篇文章是反Go的，那就是你的個(gè)人想法，而且不應(yīng)該這樣認(rèn)為。

我應(yīng)該說(shuō)，我偶爾在工作中使用Go，并有點(diǎn)想關(guān)注這門語(yǔ)言的社區(qū)。既然我不能僅憑想象就成為Go專家，但這番話并不是僅從文檔或者博客中提取出來(lái)的。但是由于我是Python開(kāi)發(fā)團(tuán)隊(duì)的一份子，無(wú)論我如何試圖表現(xiàn)得公平，固有的偏見(jiàn)某種程度上還是有的。

那么，帶著這些警告，我們來(lái)看下Go提供給開(kāi)發(fā)者什么。

生產(chǎn)率

我看待Go的方式是，使用你最喜歡的編程語(yǔ)言，移除那些難于加速生產(chǎn)率的特性，就是Go。靜態(tài)類型的影響被降到最小，因?yàn)橥ǔＶ挥性贏PI邊界時(shí)你才會(huì)面對(duì)它。結(jié)構(gòu)類型同樣使事情變得簡(jiǎn)單(把它認(rèn)為是鴨子類型)。語(yǔ)法并不笨拙(雖然它使用了花括號(hào))。不要認(rèn)為Go是C/C++去掉不安全的特性，加上生產(chǎn)率更高的東西，不然你會(huì)很失望(比如，“為什么我不能使用make()內(nèi)置函數(shù)，也不能像map類型一樣對(duì)返回值進(jìn)行計(jì)數(shù)”，這種看待Go的方式是錯(cuò)誤的;這就是為什么C++開(kāi)發(fā)者沒(méi)有轉(zhuǎn)到Go的原因)?？焖倬幾g也使開(kāi)發(fā)周期更像一個(gè)動(dòng)態(tài)語(yǔ)言，而不是一個(gè)需要編譯的語(yǔ)言。而且事實(shí)上有些人喜歡沒(méi)有異常機(jī)制帶來(lái)的冗長(zhǎng)，因?yàn)檫@促使你處理每種異常情形而不是(意外地)忽略它們(這是貫穿Go初始系統(tǒng)語(yǔ)言設(shè)計(jì)的實(shí)例)。還有，這門語(yǔ)言本身相當(dāng)短小易記，并有嚴(yán)格的前向兼容性要求(forward-compatibility requirements)(你不可能更快地獲得泛型)，大體上使用Go來(lái)編碼是件很愉快的事情。

由于是靜態(tài)類型，Go可以很容易地獲得工具支持(它對(duì)之前以此為設(shè)計(jì)目標(biāo)的語(yǔ)言也有幫助)。Go確保核心工具跟隨Go本身提供，也是明智之舉。go fmt強(qiáng)制執(zhí)行Go風(fēng)格的規(guī)則，并允許通過(guò)用戶自定義的規(guī)則來(lái)重構(gòu)代碼(“采用制表符縮進(jìn)”不再是問(wèn)題，因?yàn)檫@意味著你可以隨心所欲地設(shè)置編輯器來(lái)代表制表符，然后go fmt將其轉(zhuǎn)換為普通制表符以適用VCS)。go fix會(huì)更新代碼以跟***發(fā)布的版本保持一致。go get獲取依賴并安裝。

Go***一個(gè)生產(chǎn)率功能是它靜態(tài)編譯所有東西，使部署更簡(jiǎn)單。如果你使用容器來(lái)開(kāi)發(fā)和部署，這也不算什么。只有當(dāng)你發(fā)布單個(gè)文件的命令行工具，而不是一組依賴和你自己的代碼時(shí)，這才算得上事。

性能

就性能來(lái)說(shuō)，Go做的很好。很難指出任何基準(zhǔn)能準(zhǔn)確的證明Go總是最快的選擇，甚至計(jì)算機(jī)語(yǔ)言基準(zhǔn)游戲中一些基準(zhǔn)證明CPython 3是最快的。但是通常情況下可以認(rèn)為對(duì)于你的任何工作來(lái)說(shuō)Go已經(jīng)足夠快了。

Go真正出色的地方是并發(fā)性(concurrency) 。要注意并發(fā)代碼并不是通常誤解的并行(parallelized)代碼; 并發(fā)代碼仍然可以是單線程的，僅僅在任務(wù)切換方面更加簡(jiǎn)單/出色。Go通過(guò)使用goroutine使連續(xù)并發(fā)的代碼執(zhí)行起來(lái)絕對(duì)的簡(jiǎn)單。如果你不想使用共享內(nèi)存的方式(雖然也同樣支持)，該語(yǔ)言提供的通信管道允許以非常簡(jiǎn)潔的消息傳遞方式進(jìn)行并發(fā)編程。將所有特征整合進(jìn)此語(yǔ)言中成為盡可能使用該語(yǔ)言開(kāi)發(fā)并發(fā)代碼的又一原因。換句話說(shuō)，Go程序運(yùn)行很快，該語(yǔ)言盡力使你在合理的方式上獲得該效果。

如今的Python

如果順利的話我已經(jīng)讓你相信Go是一種優(yōu)秀的編程語(yǔ)言，除非因?yàn)槠渌?，一些人不?huì)認(rèn)為我在整篇文章對(duì)Go的描述很糟糕。現(xiàn)在我們討論一下Python的生產(chǎn)率/性能是怎么樣的。

生產(chǎn)率

首先也是最重要的，Python非常容易學(xué)習(xí)。這也是為什么在當(dāng)前高評(píng)價(jià)的美國(guó)大學(xué)中將Python作為***的教學(xué)語(yǔ)言 。這相當(dāng)于該語(yǔ)言擁有成熟穩(wěn)定的新程序員的來(lái)源以及更容易培訓(xùn)其他程序員。 我想，要說(shuō)服別人只用幾行Python代碼就會(huì)完成很多工作這并不難(Go/Python 3比較 顯示Python每次都比Go使用更少的代碼完成相同的工作)。所以我會(huì)堅(jiān)持認(rèn)為使用Python會(huì)更高產(chǎn)，即使和Go相比，這不會(huì)有人反對(duì)。

通常大家反對(duì)Python的地方是在工具支持方面。但是如果你注意到我指出的Go相關(guān)的支持工具，fmt, fix, 和 get, Python社區(qū)也有對(duì)等的工具。對(duì)遵循PEP 8的風(fēng)格格式化(style formating), 可以在提交檢查時(shí)使用pep8，或者如果想要更多go fmt風(fēng)格的自動(dòng)重寫可以使用autopep8。對(duì)用于重構(gòu)的go fix或go fmt，你可以說(shuō)2to3也可以完成同樣的功能。對(duì)于go get, Python有pip。我們有venv/virtualenv或cx_Freeze這樣的代碼凍結(jié)工具(跟其他一樣，位于容器之上?on top of containerization like anything else)，而不是靜態(tài)編譯的二進(jìn)制包。甚至有貫穿項(xiàng)目的代碼分析工具如pylint。說(shuō)Python因?yàn)槿鄙俟ぞ咧С侄荒苡糜诖笮晚?xiàng)目，這種觀點(diǎn)對(duì)我來(lái)說(shuō)是很膚淺的。

如果說(shuō)有哪方面Python完全做的好，那就一定是它豐富的第三方擴(kuò)展庫(kù)和相應(yīng)的工具可供使用，就像在PyPI上面看到的那樣(我相信肯定有人忍不住要爭(zhēng)論說(shuō)，“并不是所有的第三方庫(kù)都能夠在Python3上面運(yùn)行啊”，事實(shí)確實(shí)如此，然而，這些第三方擴(kuò)展庫(kù)對(duì)Python3的支持已經(jīng)相當(dāng)好了，而且還在繼續(xù)改善中，所以我不會(huì)太在意這個(gè)爭(zhēng)論，另外，你可以同時(shí)使用Python2/3兩個(gè)版本進(jìn)行編碼，不需要關(guān)心針對(duì)哪個(gè)版本)。看一下godoc.org，上面顯示Go也并不缺少社區(qū)支持，Pytho之所以能夠擁有更多可用的第三方庫(kù)僅僅是因?yàn)樗哪挲g，這個(gè)狀態(tài)也會(huì)繼續(xù)持續(xù)。

性能

因?yàn)镻ython已經(jīng)存在很久，且變得如此龐大， 簡(jiǎn)單地去說(shuō) “Python是足夠快的” 不能說(shuō)明整個(gè)的情況， 那是因?yàn)橛懈鞣N各樣的實(shí)現(xiàn)加速的方式。但是在深入到VM級(jí)別的選項(xiàng)之后，意味著Python的stdlib提供了獲得加速的選項(xiàng)。舉例來(lái)說(shuō)， concurrent.futures 是尷尬地執(zhí)行并行代碼的方式，這種方式是極其簡(jiǎn)單的。而在Python 3.3中，新的asyncio編寫了異步代碼。它沒(méi)有像Go那樣被集成進(jìn)語(yǔ)言，在Python中的并發(fā)程序設(shè)計(jì)是可行的，且在方式上也未必是那么痛苦的。

但是***的辦法是，你可以在選擇的VM里改變Python代碼的性能。