讀《我爲何從python轉向go》的一些感覺

一開始我覺得是一篇2013年的老帖子,沒想到居然是2015年。不懂Python不要亂噴啊。你直接說「我不懂Python,我也不肯意維護前任寫的糟糕代碼,我Go牛B,因此我要重構一遍!」我到以爲你智商正常點。。html

我以爲go不錯,可是若是不是特定領域開發,沒有足夠多成熟穩定的庫仍然很麻煩的事情。 python

http://www.jianshu.com/p/afa14e631930mysql

http://www.lupaworld.com/article-254456-1.htmlnginx

 python雖然很強大,但咱們在使用的時候也碰到了一些問題,主要由以下幾個方面:程序員

  • 動態語言sql

    python是一門動態強類型語言。可是,仍然可能出現int + string這樣的運行時錯誤,由於對於一個變量,在寫代碼的時候,咱們有時候很容易就忘記這個變量究竟是啥類型的了(點評: 真的不多遇到, 每一個函數的參數類型都有約定, 因此根本不會記不得)。docker

    在python裏面,能夠容許同名函數的出現,後一個函數會覆蓋前一個函數,有一次咱們系統一個很嚴重的錯誤就是由於這個致使的。(點評:遇到過,不過這也是不遵循約定致使的,命名不規範的緣故,在不一樣模塊採用相同的名稱是能夠的,另外這個問題在靜態語言裏也有啊,你連接到一個錯誤的庫上。 在運行時用後一個函數會覆蓋前一個函數,這也正是monkey patch存在的基礎。雖然我以爲若是在語言層面上對用戶能夠對變量的類型進行顯式聲明的約束頗有用數據庫

  • 上面說到的這些,靜態語言在編譯的時候就能幫咱們檢測出來,而不須要等到運行時出問題才知道。雖然咱們有很完善的測試用例,但總有case遺漏的狀況。因此每次出現運行時錯誤,我內心都想着若是能在編譯的時候就發現該多好。(點評: 有了編譯時檢查運行時就不出錯了麼?  難道代碼寫完了就完了麼? 差很少每次添加功能或者調試的時候,讀到感受寫的很差或者寫的不清楚的,都要作些清理,畢竟人對於所使用的庫或者語言的理解是逐步深刻的。 )django


  • 性能服務器

    其實這個一直是不少人吐槽python的地方,但python有它適合乾的事情,硬是要用python進行一些高性能模塊的開發,那也有點難爲它了。

    python的GIL致使沒法真正的多線程,你們可能會說我用多進程不就完了。但若是一些計算須要涉及到多進程交互,進程之間的通信開銷也是不得不考慮的。

    無狀態的分佈式處理使用多進程很方便,譬如處理http請求,咱們就是在nginx後面掛載了200多個django server來處理http的,但這麼多個進程天然致使總體機器負載偏高。

    但即便咱們使用了多個django進程來處理http請求,對於一些超大量請求,python仍然處理不過來。因此咱們使用openresty,將高頻次的http請求使用lua來實現。可這樣又致使使用兩種開發語言,並且一些邏輯還得寫兩份不一樣的代碼。(評:不用django,沒有發言權,不太高頻的請求能夠用Cython優化,如今的Cython已經比2013年的時候方便多了。。。


  • 同步網絡模型

    django的網絡是同步阻塞的,也就是說,若是咱們須要訪問外部的一個服務,在等待結果返回這段時間,django不能處理任何其餘的邏輯(固然,多線程的除外)。若是訪問外部服務須要很長時間,那就意味着咱們的整個服務幾乎在很長一段時間徹底不可用。

    爲了解決這個問題,咱們只能不斷的多開django進程,同時須要保證全部服務都能快速的處理響應,但想一想這實際上是一件很不靠譜的事情。


  • 異步網絡模型

    tornado的網絡模型是異步的,這意味着它不會出現django那樣由於外部服務不可用致使這個服務沒法響應的問題。話說,比起django,我但是很是喜歡tornado的,小巧簡單,之前還寫過幾篇深刻剖析tornado的文章了。雖然tornado是異步的,可是python的mysql庫都不支持異步,這也就意味着若是咱們在tornado裏面訪問數據庫,咱們仍然可能面臨由於數據庫問題形成的整個服務不可用。(評:歷史緣由,幾乎全部Python的標準庫都是同步的,)

  • 其實異步模型最大的問題在於代碼邏輯的割裂,由於是事件觸發的,因此咱們都是經過callback進行相關處理,因而代碼裏面就常常出現幹一件事情,傳一個callback,而後callback裏面又傳callback的狀況,這樣的結果就是整個代碼邏輯很是混亂。python沒有原生的協程支持,雖然能夠經過gevent,greenlet這種的上patch方式來支持協程,但畢竟更改了python源碼。另外,python的yield也能夠進行簡單的協程模擬,但畢竟不能跨堆棧,侷限性很大,不知道3.x的版本有沒有改進。點評: Python3.4引入asyncioPython3.5引入的async和await,就算使用Twisted,也不會一堆callback啊。有沒有搞錯?不清楚跨堆棧


  • 開發運維部署

    當我第一次使用python開發項目,我是沒成功安裝上項目須要的包的,光安裝成功mysql庫就弄了好久。後來,是一位同事將他整個python目錄打包給我用,我才能正常的將項目跑起來。話說,如今有了docker,是多麼讓人幸福的一件事情。(點評: 沒有用過虛擬Python環境?virtualenv,python直接調用mysql connector,怎麼會裝一堆庫?不明因此

    而部署python服務的時候,咱們須要在服務器上面安裝一堆的包,光是這一點就讓人很麻煩,雖然能夠經過puppet,salt這些自動化工具解決部署問題,但相比而言,靜態編譯語言只用扔一個二進制文件,可就方便太多了。( 點評:測試環境就是開發環境,你肯定靜態編譯的不解決好依賴在別的機子上面就能跑?)


  • 代碼失控

    python很是靈活簡單,寫c幾十行代碼才能搞定的功能,python一行代碼沒準就能解決。可是太簡單,反而致使不少同窗沒法對代碼進行深層次的思考,對整個架構進行細緻的考量。來了一個需求,啪啪啪,鍵盤敲完開速實現,結果就是代碼愈來愈混亂,最終致使了整個項目代碼失控。

    雖然這也有咱們自身的緣由,譬如沒好的代碼review機制,沒有好的項目規範,但我的感受,若是一個程序員沒通過良好的編碼訓練,用python很容易就寫出爛的代碼,由於太自由了。

    固然,我這裏並非說用python沒法進行大型項目的開發,豆瓣,dropbox都是很好的例子,只是在咱們項目中,咱們的python代碼失控了。(點評:好像沒有據說用了那種語言代碼就不失控了,這根本就是拒絕小步重構,代碼模塊化差,模塊耦合度高等等一系列問題致使的,Python的實現代碼少,反而可以有精力進行持續的快速改進。。

上面提到的都是咱們在實際項目中使用python遇到的問題,雖然最終都解決了,可是讓我愈發的以爲,隨着項目複雜度的增大,流量性能壓力的增大,python並非一個很好的選擇。


(點評: Python存在問題嗎? 固然也有不少,好比

* 配套的異步庫太少且缺少維護。

* 不能限制變量的類型(雖然有Python3.5的type hints,可是和註釋沒啥區別)

* 自己的計算性能比V8引擎的JavaScript要差不少(能夠藉助C)

相關文章
相關標籤/搜索