你好目前go語言軟件包相對較少。其開發(fā)的docker。文明于世。Python模塊包超級多。語法簡練。而且開發(fā)周期短。適合短期項目。go適合做后臺開發(fā)和分布式開發(fā)。所以選取那種語言其實要看場合。語言沒有好壞。也沒必要放棄誰學(xué)誰。有能力多學(xué)一門。畢竟技多不壓身。祝你順利。
創(chuàng)新互聯(lián)是一家專注于成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計與策劃設(shè)計,蒙陰網(wǎng)站建設(shè)哪家好?創(chuàng)新互聯(lián)做網(wǎng)站,專注于網(wǎng)站建設(shè)十年,網(wǎng)設(shè)計領(lǐng)域的專業(yè)建站公司;建站業(yè)務(wù)涵蓋:蒙陰等地區(qū)。蒙陰做網(wǎng)站價格咨詢:18980820575
轉(zhuǎn)載請參見文章末尾處的要求。【感謝張佳偉(@ghosert)的熱心翻譯。如果其他朋友也有不錯的原創(chuàng)或譯文,可以嘗試推薦給伯樂在線。】這是一篇(長)博文, 介紹了我們在 Repustate 遷移大量 Python/Cython 代碼到 Go 語言的經(jīng)驗。如果你想了解整個故事,背景和所有的事情,請繼續(xù)往下讀。如果你只是想了解 Python 開發(fā)者在一頭扎進(jìn) Go 語言前需要了解什么,請點擊一下鏈接:從Python遷移到Go的建議(Tips Tricks) 背景在Repustate,我們完成過的最棒的技術(shù)成就之一是實現(xiàn)了阿拉伯語的情感分析。阿拉伯語是一塊難啃的硬骨頭,因為它的詞形變化相當(dāng)復(fù)雜。比起譬如英語,阿拉伯語的分詞(將一個句子切分呈幾個獨立的單詞)也更困難,因為阿拉伯語的單詞本身還可能會包含空白字符(例如:“阿列夫”在一個單詞里的位置)。這也談不上是泄密,Repustate 使用支持向量機(jī)(SVM)來獲取一個句子背后最有可能的含義,并在其中加上情感元素。 總體上來說,我們使用了 22 種模型(22 個 SVM) 并且在一篇文檔中,每一個單詞我們都會加以分析。因此如果你有一篇 500 字的文檔,那么基于 SVM,會進(jìn)行十萬次的比較。 PythonRepustate 幾乎完全就是一個 Python 商店。我們使用 Django 來實現(xiàn) API 和網(wǎng)站。因此(目前)為了保持代碼一致,同時使用 Python 來實現(xiàn)阿拉伯語情感引擎是合情合理的。只是做原型和實現(xiàn)的話,Python 是很好的選擇。它的表達(dá)能力很強(qiáng)悍,第三方類庫等等也很好。如果你就是為了Web服務(wù),Python 很完美。但是當(dāng)你進(jìn)行低級別的計算,大量依賴于哈希表(Python 里的字典類型)做比較的時候,一切都變慢了。我們每秒能處理大約兩到三個阿拉伯文檔,但是這太慢了。比較下來,我們的英語情感引擎每秒能處理大約五百份文檔。 瓶頸因此我們開啟了 Python 分析器,開始調(diào)查是什么地方用了那么長時間。還記得我前面說過我們有 22 個 SVM 并且每個單詞都需要經(jīng)過處理嗎?好吧,這些都是線性處理的,非并行處理。所以我們的第一反應(yīng)是把線性處理改成 map/reduce 那樣的操作。簡單來說:Python 不太適合用作 map/reduce。當(dāng)你需要并發(fā)的時候,Python 算上好用。在 2013 Python 大會上(譯者:PyCon 2013),Guido 談到了 Tulip,他的這個新項目正在彌補(bǔ) Python 這方面的不足,不過得過段一段時間才能推出,但是如果已經(jīng)有了更好用的東西,我們?yōu)槭裁催€要等呢? 選Go 語言,還是回家算了?我在Mozilla的朋友告訴我,Mozilla 內(nèi)部正在將他們大量的基礎(chǔ)日志架構(gòu)切換到 Go 語言上,部分原因是因為強(qiáng)大的 [goroutines]。Go 語言是 Google 的人設(shè)計的,并且在設(shè)計之初就把支持并發(fā)作為第一要務(wù),而不是像 Python 的各種解決方案那樣是事后才加上去的。因此我們開始著手把 Python 換成 Go 語言。雖然Go 代碼還不算正式上線的產(chǎn)品,但是結(jié)果非常令人鼓舞。我們現(xiàn)在能做到每秒處理一千份文檔,使用更少的內(nèi)存,還不用調(diào)試你在 Python 里遇到:丑陋的多進(jìn)程/gevent/“為什么 Control-C 殺不了進(jìn)程”這些問題。 為什么我們喜歡 Go 語言任何人,對編程語言是如何工作(解釋型 vs 編譯型, 動態(tài)語言 vs 靜態(tài)語言)有一點理解的話,會說,“切,當(dāng)然 Go 語言會更快”。是的,我們也可以用 Java 把所有的東西重寫一遍,也能看到類似更快的改善,但那不是 Go 語言勝出的原因。你用 Go 寫的代碼好像就是對的。我搞不清楚到底是怎么回事,但是一旦代碼被編譯了(編譯速度很快),你就會覺得這代碼能工作(不只是跑起來不會錯,而且甚至邏輯上也是對的)。我知道,這聽上去不太靠譜,但是確實如此。這和 Python 在冗余(或非冗余)方面非常類似,它把函數(shù)作為第一目標(biāo),因此函數(shù)編程會很容易想明白。而且當(dāng)然,go 線程和通道讓你的生活更容易,你可以得到靜態(tài)類型帶來的性能大提升,還能更精細(xì)的控制內(nèi)存分配,而你卻不必為此在語言表達(dá)力上付出太多的代價。 希望能早點知道的事情(Tips Tricks)除去所有這些贊美之詞以后,有時你真的需要在處理 Go 代碼的時候,相對于 Python,改變一下思維方式。因此這是我在遷移代碼時記錄的筆記清單 —— 只是在我把 Python 代碼轉(zhuǎn)換到 Go 時從我腦子里隨機(jī)冒出來的點子:沒有內(nèi)建的集合類型(必須使用map,并檢查是否存在)因為沒有集合,必須自己寫交集,并集之類的方法沒有tuples 類型,必須寫你自己的結(jié)構(gòu),或者使用 slices (即數(shù)組)沒有類似 \__getattr__() 的方法,你必須總是檢查存在性,而不是設(shè)置默認(rèn)值,例如,在 Python 里,你可以這樣寫 value = dict.get(“a_key”, “default_value”)必須總是檢查錯誤(或者顯式的忽略錯誤)不能有變量/包沒被使用,因此簡單的測試也需要有時注掉一些代碼在[] byte 和 string 之間轉(zhuǎn)換。 regexp 使用 [] byte (不可變)。這是對的,但是老把一些變量轉(zhuǎn)換來轉(zhuǎn)換去很煩人Python 更寬松。你可以使用超出范圍的索引在字符串里取一個片段,而且不會出錯。你還可以用負(fù)數(shù)取出片段,但是 Go 不行你不能混合數(shù)據(jù)結(jié)構(gòu)類型。也許這樣也不太干凈,但是有時在 Python 里,我會使用值是混合了字符串和列表的字典。但是 Go 不行,你不得不清理干凈你的數(shù)據(jù)結(jié)構(gòu)或者使用自定義的結(jié)構(gòu)不能解包一個 tuple 或者 list 到幾個不同的變量(例如:x, y, z = [1, 2, 3])駝峰式命名風(fēng)格(如果你沒有首字大寫方法名/結(jié)構(gòu)名,他們不會被暴露給其它的包)。我更喜歡 Python 的小寫字母加下劃線命名風(fēng)格。必須顯式檢查是否有錯誤 != nil, 不像在 Python 里,許多類型可以像 bool 那樣檢查 (0, “”, None 都可以被解釋成 “非” 集合)文檔在一些模塊上太散亂了,例如(crypto/md5),但是 IRC 上的 go-nuts 很好用,提供了巨大的幫助。從數(shù)字到字符串的轉(zhuǎn)換(int64 - string) 和 []byte - string (只要使用 string([]byte))不太一樣。需要使用 strconv。閱讀Go 代碼比起 Python 那樣寫起來如偽代碼的語言更像一門編程語言, Go 有更多的非字母數(shù)字字符,并且使用 || 和 , 而不是 “or”和“and”寫一個文件的話,有 File.Write([]byte) 和 File.WriteString(string), 這點和 Python 開發(fā)者的 Python 之道:“解決問題就一種方法 ”相違背。修改字符串很困難,必須經(jīng)常重排 fmt.Sprintf沒有構(gòu)造函數(shù),因此慣用法是創(chuàng)建 NewType() 方法來返回你要的結(jié)構(gòu)Else (或者 else if)必須正確格式化,else 得和 if 配對的大括號在同一行。奇怪。賦值運算符取決于在函數(shù)內(nèi)還是函數(shù)外,例如,= 和 :=如果我只想要“鍵”或者只想要 “值”,譬如: dict.keys() 或者 dict.values(),或者一個 tuples 的列表,例如:dict.items(),在 Go 語言里沒有等價的東西,你只能自己枚舉 map 來構(gòu)造你的列表類型我有時使用一種習(xí)慣用法:構(gòu)造一個值是函數(shù)的字典類型,我想通過給定的鍵值調(diào)用這些函數(shù),你在 Go 里可以做到,但是所有的函數(shù)必須接受,返回相同的東西,例如:相同的方法簽名如果你使用 JSON 并且 你的 JSON 是一個復(fù)合類型,恭喜你。 你必須構(gòu)造自定義的結(jié)構(gòu)匹配 JSON 塊里的格式,然后把原始 JSON 解析到你自定義結(jié)構(gòu)的實例中去。比起 Python 世界里 object = json.loads(json_blob) 要做更多的工作 是不是值得?值得,一百萬倍的值得。速度的提升太多了,以致很難舍棄。同時,我認(rèn)為, Go 是目前趨勢所在,因此在招新員工的時候,我認(rèn)為把 Go 當(dāng)作 Repustate 技術(shù)積累的重要一環(huán)會很有幫助。]
在Go語言中,規(guī)定的方式是,函數(shù)返回錯誤信息。這沒什么。如果一個文件并不存在,op.Open函數(shù)會返回一個錯誤信息。這沒什么。如果你向你一個中斷了的網(wǎng)絡(luò)連接里寫數(shù)據(jù),net.Conn里的Write方法會返回一個錯誤。這沒什么。這種狀況在這種程序中是可以預(yù)料到的。這種操作就是容易失敗,你知道程序會如何運行,因為API的設(shè)計者通過內(nèi)置了一種錯誤情況的結(jié)果而讓這一切顯得很清楚。
從另一方面講,有些操作基本上不會出錯,所處的環(huán)境根本不可能給你提示錯誤信息,不可能控制錯誤。這才是讓人痛苦的地方。典型的例子;一個程序執(zhí)行
x[j],j值超出數(shù)組邊界,這才痛苦。像這樣預(yù)料之外的麻煩在程序中是一個嚴(yán)重的bug,一般會弄死程序的運行。不幸的是,由于這種情況的存在,我們很難寫出健壯的,具有自我防御的服務(wù)器——例如,可以應(yīng)付偶然出現(xiàn)的有bug的HTTP請求處理器時,不影響其他服務(wù)的啟動和運行。為解決這個問題,我們引入了恢復(fù)機(jī)制,它能讓一個go例程從錯誤中恢復(fù),服務(wù)余下設(shè)定的調(diào)用。然而,代價是,至少會丟失一個調(diào)用。這是特意而為之的。引用郵件中的原話:“這種設(shè)計不同于常見的異常控制結(jié)構(gòu),這是一個認(rèn)真思考后的決定。我們不希望像java語言里那樣把錯誤和異常混為一談。”
我剛開始提到的那篇文章里問“為什么數(shù)組越界造成的麻煩會比錯誤的網(wǎng)址或斷掉的網(wǎng)絡(luò)引出的問題要大?”答案是,我們沒有一種內(nèi)聯(lián)并行的方法來報告在執(zhí)行x[j]期間產(chǎn)生的錯誤,但我們有內(nèi)聯(lián)并行的方法報告由錯誤網(wǎng)址或網(wǎng)絡(luò)問題造成的錯誤。
使用Go語言中的錯誤返回模式的規(guī)則很簡單:如果你的函數(shù)在某種情況下很容易出錯,那它就應(yīng)該返回錯誤。當(dāng)我調(diào)用其它的程序庫時,如果它是這樣寫的,那我不必?fù)?dān)心那些錯誤的產(chǎn)生,除非有真正異常的狀況,我根本沒有想到需要處理它們。
有一個你需要記在心里的事情是,Go語言是為大型軟件設(shè)計的。我們都喜歡程序簡潔清晰,但對于一個由很多程序員一起開發(fā)的大型軟件,維護(hù)成本的增加很難讓程序簡潔。異常捕捉模式的錯誤處理方式的一個很有吸引力的特點是,它非常適合小程序。但對于大型程序庫,如果對于一些普通操作,你都需要考慮每行代碼是否會拋出異常、是否有必要捕捉處理,這對于開發(fā)效率和程序員的時間來說都是非常嚴(yán)重的拖累。我自己做開發(fā)大型Python軟件時感受到了這個問題。
Go語言的返回錯誤方式,不可否認(rèn),對于調(diào)用者不是很方便,但這樣做會讓程序中可能會出錯的地方顯的很明顯。對于小程序來說,你可能只想打印出錯誤,退出程序。對于一些很精密的程序,根據(jù)異常的不同,來源的不同,程序會做出不同的反應(yīng),這很常見,這種情況中,try
+
catch的方式相對于錯誤返回模式顯得冗長。當(dāng)然,Python里的一個10行的代碼放到Go語言里很可能會更冗長。畢竟,Go語言主要不是針對10行規(guī)模的程序的。
就是要說明這一點:Go語言程序員認(rèn)為,把error作為一種內(nèi)置的類型是非常重要的。
當(dāng)前文章:python轉(zhuǎn)go語言 python和go語言
本文URL:http://m.kartarina.com/article30/dodecso.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站制作、搜索引擎優(yōu)化、網(wǎng)站收錄、品牌網(wǎng)站建設(shè)、微信公眾號、網(wǎng)站維護(hù)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)