首先這是一篇翻譯自TJ 的 Farewell Node.js  ，我本人在看完這這篇文章之后確實(shí)是受到了一些沖擊，但我并不認(rèn)同作者的某些看法，比如我認(rèn)為 Node.js 的package register 是其許多優(yōu)勢(shì)之一，反而 Go 在這方面卻略顯匱乏。 由于個(gè)人水平所限，在翻譯的時(shí)候有許多不懂的地方，我也去作者博客、stackoverflow 上問了一些問題，獲得了解答。翻譯仍有許多不到位的地方，希望能獲得指出意見。

PS.  作為一位Node.js 的入門菜鳥，感謝TJ 的付出，一路走好。

正文：

告別Node.js

離開Node.js領(lǐng)域

我一直與Node.js在生產(chǎn)中一起戰(zhàn)斗了足夠久的時(shí)間，很不幸的是，既然我已經(jīng)不再喜歡從事這份工作，至少在此刻，這是我的正式告別。更重要的是，我需要維護(hù)者。

        Node在一些方面確實(shí)很棒，但對(duì)于最近我感興趣的軟件類型，它終究不是適合的工具。我仍然計(jì)劃用Node做網(wǎng)站，但如果你對(duì)維護(hù)任何項(xiàng)目感興趣，只需要留言寫下你的Github 用戶名 ，  npm 用戶名，以及項(xiàng)目名稱來讓我知道。通常我所要求的只有你不徹底的改變已有的api，如果真要這么做的話，還是重新開一個(gè)新項(xiàng)目的好。

         Koa  是一個(gè)我會(huì)繼續(xù)去維護(hù)的項(xiàng)目。(與Co 還有朋友們一塊)

圣杯的故事

我一直深愛著C，但每一個(gè)從事C開發(fā)工作的人都知道它是有價(jià)值卻又易于出錯(cuò)的。很難在日常工作中證明語(yǔ)言的選擇，因?yàn)樗煌耆亲羁斓墓ぷ鳌：?jiǎn)潔也是一直贊美它的原因，但是沒有大量的模板你不會(huì)走得很遠(yuǎn)。

隨著越多的參與分布式系統(tǒng)的開發(fā)，Node性能高過可用性與健壯性的發(fā)展趨勢(shì)讓我越發(fā)沮喪。在過去的一個(gè)星期中，我已經(jīng)用Go重寫了一個(gè)相對(duì)大型的分布式系統(tǒng)，它的健壯性、性能更好，并且易于維護(hù)，由于同步代碼普遍的更加優(yōu)美并且更易于開發(fā)，它有著更好的可測(cè)試覆蓋范圍。

        我并不是說Go就是一個(gè)圣杯，它并不完美，但對(duì)于現(xiàn)今存在的多種語(yǔ)言來說，Go于我是一個(gè)極好的答案。隨著越來越多的這些"次世代"語(yǔ)言如 Rust 和 Julia 找到他們自己的位置并成熟起來，我確定我們會(huì)有更多的偉大的解決方案。

        個(gè)人而言我對(duì)Go語(yǔ)言感到很興奮是因?yàn)樗牡俣龋芗?dòng)的看到他們渴望去達(dá)到2.0版本，并且據(jù)我所聽到的消息，他們并不害怕與打破原有的偉大事物。如果是真的話我很樂意，更多是因?yàn)槲蚁嘈湃绻娴氖怯幸嬗谶@門語(yǔ)言的，就應(yīng)該快速的打破已有事物。但我也不是一個(gè)運(yùn)行了大量系統(tǒng)的軟件巨人。:D

        編著: 一定是我錯(cuò)誤解讀了一些提交的郵件列表，他們?cè)谌魏螘r(shí)候都并不渴望于做出一些破壞性的改變。@enneff

為什么是Go?

如果Node對(duì)你有效并且你沒有什么需要擔(dān)心的，它仍然是一個(gè)很好的工具。但如果有些事情困擾著你，別忘了跳出你的盒子去看看在盒子外面有什么其他的--在最初的使用Go來構(gòu)建產(chǎn)品的幾個(gè)小時(shí)內(nèi)，我已經(jīng)被吸引住了。

再次聲明，我并不是在那里說Go絕對(duì)是最好的語(yǔ)言而且你必須去使用它。但對(duì)于它所處年紀(jì)來說，是非常成熟而健壯的。(大致與Node相同年紀(jì)的時(shí)候)。類型的重構(gòu)是有趣而簡(jiǎn)單的，Go所提供的作業(yè)和調(diào)試工具是很棒的，同時(shí)社區(qū)具有非常強(qiáng)大的關(guān)于文檔、格式、基準(zhǔn)以及api設(shè)計(jì)方面的條例。

        在如此習(xí)慣于極度模塊化的Node 和體驗(yàn)過 Ruby 腐爛的標(biāo)準(zhǔn)庫(kù)的同時(shí)，當(dāng)我第一次聽到 Go，我認(rèn)為它的標(biāo)準(zhǔn)庫(kù)是糟糕的。在我深入這門語(yǔ)言之后，我意識(shí)到現(xiàn)階段極大部分的標(biāo)準(zhǔn)庫(kù)都是很有必要的，比如compression、json、IO、buffered IO、字符串操作等等。大部分的這些APIS 都被定義的很好并且很強(qiáng)大。很容易僅僅通過使用這些標(biāo)準(zhǔn)庫(kù)來書寫整個(gè)程序。

第三方Go packages

大部分的Go 庫(kù)看上去都很相似，我到目前為止所使用過的大部分的第三方代碼都是高質(zhì)量的，而在Node中很難去找到這些因?yàn)镴avaScript 吸引了不同技巧層次范圍內(nèi)的開發(fā)者。

        對(duì)于Go 的packages 來說，沒有注冊(cè)中心，所以你通常會(huì)同時(shí)看到5或6種相同的包。在有些時(shí)候，這會(huì)造成一定的困惑，但它卻有一個(gè)有趣的副作用，你必須通過認(rèn)真的審查每個(gè)包來決定哪一個(gè)是最佳方案。通過Node 通常有規(guī)范的包如 "redis","mongodb-native" 或者"zeromq"，所以你會(huì)停在那里就推斷出他們是最好的一個(gè)。

        如果你正在做一些分布式的工作，你會(huì)發(fā)現(xiàn)Go的令人印象深刻的并發(fā)基礎(chǔ)數(shù)據(jù)類型是非常有幫助的。我們可以通過在Node 中的generators 來獲得相似的東西，但在我看來，generators 僅僅是做到一半而已。沒有獨(dú)立的錯(cuò)誤處理、報(bào)告棧即使最好也仍然是平凡的。當(dāng)這些方案都能良好運(yùn)行的時(shí)，我也不想等待社區(qū)三年去重整。

 在我看來，Go的錯(cuò)誤處理是出眾的。就你必須考慮每一個(gè)錯(cuò)誤并且決定怎么做而言，Node是偉大的。然而Node 失敗在:

你或許會(huì)重復(fù)的進(jìn)行回調(diào)

你或許根本不會(huì)進(jìn)行回調(diào) 迷失在不穩(wěn)定狀態(tài)中 (譯注 比如忘記傳遞錯(cuò)誤處理回調(diào)，錯(cuò)誤時(shí)，Node 將吞掉這個(gè)錯(cuò)誤而不會(huì)有任何反饋）

你或許會(huì)得到外帶的錯(cuò)誤

emitters 或許會(huì)獲得多個(gè)錯(cuò)誤的事件

忘記錯(cuò)誤的事件的處理會(huì)毀掉一切

經(jīng)常不確定什么需要錯(cuò)誤的處理

錯(cuò)誤的處理是非常冗余的

回調(diào)爛透了
在Go語(yǔ)言中，當(dāng)我的代碼結(jié)束的時(shí)候，它就結(jié)束了，你不能在語(yǔ)句中重新執(zhí)行。在Node中這是不確定的。你會(huì)認(rèn)為一個(gè)程序完全的執(zhí)行完畢，直到一個(gè)庫(kù)意外的多次調(diào)用一個(gè)回調(diào)，或者沒有正確的清除handlers 然后引起代碼的再次執(zhí)行。實(shí)際的生產(chǎn)代碼中找到這些原因是相當(dāng)困難的，為什么要煩惱這些？其他語(yǔ)言不會(huì)讓你經(jīng)歷這些痛苦。

未來的Node

我仍然希望Node 做得很好，許多的人對(duì)他進(jìn)行巨額的投資，它確實(shí)有這樣的潛質(zhì)。我認(rèn)為Joyent 和團(tuán)隊(duì)需要關(guān)注在可用性—如果你的應(yīng)用很脆弱并且很困難去調(diào)試、重構(gòu)以及開發(fā)，性能是無意義的。

        在4-5年內(nèi)我們?nèi)匀粚⒂兄@種模糊不清的錯(cuò)誤 "Error: getaddrinfo EADDRINFO”，這個(gè)事實(shí)告訴我們Node 的發(fā)展優(yōu)先級(jí)在哪里。可理解的是，當(dāng)你專注于建立系統(tǒng)核心的時(shí)候，會(huì)很容易漏掉這些東西。單我認(rèn)為用戶已經(jīng)對(duì)這類事物一次又一次的表達(dá)了意見卻沒看到任何的結(jié)果。對(duì)于聲稱說我們擁有的已經(jīng)是完美的，我們通常獲得少數(shù)的回應(yīng)。在實(shí)踐中，卻并非如此。

       streams 是被中斷的, 回調(diào)不容易使用，錯(cuò)誤含糊不清，工具并不好用，社區(qū)條例是有，相對(duì)于Go而言卻顯得匱乏。盡管如此，一些特定的任務(wù)我仍可能繼續(xù)去使用Node，比如創(chuàng)建網(wǎng)頁(yè)，或者一些零散的API或者原型。如果Node可以修復(fù)一些它的基本問題，那么它有機(jī)會(huì)保持相關(guān)性，但當(dāng)存在另一方案是更高的性能和更高的可用性的時(shí)候性能高于可用性的論證不會(huì)走的太遠(yuǎn)。

 如果Node社區(qū)決定去擁抱generators 并能在Node 非常核心的地方實(shí)現(xiàn)他們，去適當(dāng)?shù)膫鬟f錯(cuò)誤，是有機(jī)會(huì)讓這個(gè)是可參照的。這會(huì)徹底的提高Node 的可用性以及健壯性。

 好消息是，不久之前我跟在 StrongLoop  里面的貢獻(xiàn)核心代碼的了不起并充滿天賦的家伙聊過。他們正在明確的采用通過傾聽開發(fā)者對(duì)這個(gè)平臺(tái)的回復(fù)，并且計(jì)劃找到修復(fù)這些問題去修復(fù)的正確方式讓未來的Node更加易于工作。我不確定多家公司對(duì)核心部分同時(shí)開發(fā)的沖突會(huì)如何結(jié)束，但我希望開發(fā)者驅(qū)動(dòng)方會(huì)勝出。

        這并不意味著這是一個(gè)對(duì)個(gè)人的攻擊，很多真的有天賦的人們正在與Node或在Node之上工作，但這再也不是我感興趣的地方了。我在Node社區(qū)中經(jīng)歷了一段偉大時(shí)光的同時(shí)也遇到了一些真的很有趣的人。

        故事的寓意在于，不要被你自己的圈子所限制?。】纯雌渌胤接惺裁?，你也許會(huì)再次享受編程。在這之外還有很多了不起的解決方案，我犯的錯(cuò)在于等了太久才去與他們一起游戲！

最新評(píng)論