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

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

正文：

告別Node.js

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

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

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

         Koa  是一個我會繼續(xù)去維護的項目。(與Co 還有朋友們一塊)

圣杯的故事

我一直深愛著C，但每一個從事C開發(fā)工作的人都知道它是有價值卻又易于出錯的。很難在日常工作中證明語言的選擇，因為它不完全是最快的工作。簡潔也是一直贊美它的原因，但是沒有大量的模板你不會走得很遠(yuǎn)。

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

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

        個人而言我對Go語言感到很興奮是因為他的迭代速度，很激動的看到他們渴望去達(dá)到2.0版本，并且據(jù)我所聽到的消息，他們并不害怕與打破原有的偉大事物。如果是真的話我很樂意，更多是因為我相信如果真的是有益于這門語言的，就應(yīng)該快速的打破已有事物。但我也不是一個運行了大量系統(tǒng)的軟件巨人。:D

        編著: 一定是我錯誤解讀了一些提交的郵件列表，他們在任何時候都并不渴望于做出一些破壞性的改變。@enneff

為什么是Go?

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

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

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

第三方Go packages

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

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

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

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

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

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

你或許會得到外帶的錯誤

emitters 或許會獲得多個錯誤的事件

忘記錯誤的事件的處理會毀掉一切

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

錯誤的處理是非常冗余的

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

未來的Node

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

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

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

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

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

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

        故事的寓意在于，不要被你自己的圈子所限制??！看看其他地方有什么，你也許會再次享受編程。在這之外還有很多了不起的解決方案，我犯的錯在于等了太久才去與他們一起游戲！

最新評論