首先這是一篇翻譯自TJ 的 Farewell Node.js ，我本人在看完這這篇文章之後確實是受到了一些沖擊，但我並不認同作者的某些看法，比如我認為 Node.js 的package register 是其許多優勢之一，反而 Go 在這方面卻略顯匮乏。 由於個人水平所限，在翻譯的時候有許多不懂的地方，我也去作者博客、stackoverflow 上問了一些問題，獲得了解答。翻譯仍有許多不到位的地方，希望能獲得指出意見。
PS. 作為一位Node.js 的入門菜鳥，感謝TJ 的付出，一路走好。
正文：
告別Node.js
離開Node.js領域
我一直與Node.js在生產中一起戰斗了足夠久的時間，很不幸的是，既然我已經不再喜歡從事這份工作，至少在此刻，這是我的正式告別。更重要的是，我需要維護者。
Node在一些方面確實很棒，但對於最近我感興趣的軟件類型，它終究不是適合的工具。我仍然計劃用Node做網站，但如果你對維護任何項目感興趣，只需要留言寫下你的Github 用戶名 ， npm 用戶名，以及項目名稱來讓我知道。通常我所要求的只有你不徹底的改變已有的api，如果真要這麼做的話，還是重新開一個新項目的好。
Koa 是一個我會繼續去維護的項目。(與Co 還有朋友們一塊)
聖杯的故事
我一直深愛著C，但每一個從事C開發工作的人都知道它是有價值卻又易於出錯的。很難在日常工作中證明語言的選擇，因為它不完全是最快的工作。簡潔也是一直贊美它的原因，但是沒有大量的模板你不會走得很遠。
隨著越多的參與分布式系統的開發，Node性能高過可用性與健壯性的發展趨勢讓我越發沮喪。在過去的一個星期中，我已經用Go重寫了一個相對大型的分布式系統，它的健壯性、性能更好，並且易於維護，由於同步代碼普遍的更加優美並且更易於開發，它有著更好的可測試覆蓋范圍。
我並不是說Go就是一個聖杯，它並不完美，但對於現今存在的多種語言來說，Go於我是一個極好的答案。隨著越來越多的這些"次世代"語言如 Rust 和 Julia 找到他們自己的位置並成熟起來，我確定我們會有更多的偉大的解決方案。
個人而言我對Go語言感到很興奮是因為他的迭代速度，很激動的看到他們渴望去達到2.0版本，並且據我所聽到的消息，他們並不害怕與打破原有的偉大事物。如果是真的話我很樂意，更多是因為我相信如果真的是有益於這門語言的，就應該快速的打破已有事物。但我也不是一個運行了大量系統的軟件巨人。:D
編著: 一定是我錯誤解讀了一些提交的郵件列表，他們在任何時候都並不渴望於做出一些破壞性的改變。@enneff
為什麼是Go?
如果Node對你有效並且你沒有什麼需要擔心的，它仍然是一個很好的工具。但如果有些事情困擾著你，別忘了跳出你的盒子去看看在盒子外面有什麼其他的--在最初的使用Go來構建產品的幾個小時內，我已經被吸引住了。
再次聲明，我並不是在那裡說Go絕對是最好的語言而且你必須去使用它。但對於它所處年紀來說，是非常成熟而健壯的。(大致與Node相同年紀的時候)。類型的重構是有趣而簡單的，Go所提供的作業和調試工具是很棒的，同時社區具有非常強大的關於文檔、格式、基准以及api設計方面的條例。
在如此習慣於極度模塊化的Node 和體驗過 Ruby 腐爛的標准庫的同時，當我第一次聽到 Go，我認為它的標准庫是糟糕的。在我深入這門語言之後，我意識到現階段極大部分的標准庫都是很有必要的，比如compression、json、IO、buffered IO、字符串操作等等。大部分的這些APIS 都被定義的很好並且很強大。很容易僅僅通過使用這些標准庫來書寫整個程序。
第三方Go packages
大部分的Go 庫看上去都很相似，我到目前為止所使用過的大部分的第三方代碼都是高質量的，而在Node中很難去找到這些因為JavaScript 吸引了不同技巧層次范圍內的開發者。
對於Go 的packages 來說，沒有注冊中心，所以你通常會同時看到5或6種相同的包。在有些時候，這會造成一定的困惑，但它卻有一個有趣的副作用，你必須通過認真的審查每個包來決定哪一個是最佳方案。通過Node 通常有規范的包如 "redis","mongodb-native" 或者"zeromq"，所以你會停在那裡就推斷出他們是最好的一個。
如果你正在做一些分布式的工作，你會發現Go的令人印象深刻的並發基礎數據類型是非常有幫助的。我們可以通過在Node 中的generators 來獲得相似的東西，但在我看來，generators 僅僅是做到一半而已。沒有獨立的錯誤處理、報告棧即使最好也仍然是平凡的。當這些方案都能良好運行的時，我也不想等待社區三年去重整。
在我看來，Go的錯誤處理是出眾的。就你必須考慮每一個錯誤並且決定怎麼做而言，Node是偉大的。然而Node 失敗在:
你或許會重復的進行回調
你或許根本不會進行回調 迷失在不穩定狀態中 (譯注 比如忘記傳遞錯誤處理回調，錯誤時，Node 將吞掉這個錯誤而不會有任何反饋）
你或許會得到外帶的錯誤
emitters 或許會獲得多個錯誤的事件
忘記錯誤的事件的處理會毀掉一切
經常不確定什麼需要錯誤的處理
錯誤的處理是非常冗余的
回調爛透了
在Go語言中，當我的代碼結束的時候，它就結束了，你不能在語句中重新執行。在Node中這是不確定的。你會認為一個程序完全的執行完畢，直到一個庫意外的多次調用一個回調，或者沒有正確的清除handlers 然後引起代碼的再次執行。實際的生產代碼中找到這些原因是相當困難的，為什麼要煩惱這些？其他語言不會讓你經歷這些痛苦。
未來的Node
我仍然希望Node 做得很好，許多的人對他進行巨額的投資，它確實有這樣的潛質。我認為Joyent 和團隊需要關注在可用性—如果你的應用很脆弱並且很困難去調試、重構以及開發，性能是無意義的。
在4-5年內我們仍然將有著這種模糊不清的錯誤 "Error: getaddrinfo EADDRINFO”，這個事實告訴我們Node 的發展優先級在哪裡。可理解的是，當你專注於建立系統核心的時候，會很容易漏掉這些東西。單我認為用戶已經對這類事物一次又一次的表達了意見卻沒看到任何的結果。對於聲稱說我們擁有的已經是完美的，我們通常獲得少數的回應。在實踐中，卻並非如此。
streams 是被中斷的, 回調不容易使用，錯誤含糊不清，工具並不好用，社區條例是有，相對於Go而言卻顯得匮乏。盡管如此，一些特定的任務我仍可能繼續去使用Node，比如創建網頁，或者一些零散的API或者原型。如果Node可以修復一些它的基本問題，那麼它有機會保持相關性，但當存在另一方案是更高的性能和更高的可用性的時候性能高於可用性的論證不會走的太遠。
如果Node社區決定去擁抱generators 並能在Node 非常核心的地方實現他們，去適當的傳遞錯誤，是有機會讓這個是可參照的。這會徹底的提高Node 的可用性以及健壯性。
好消息是，不久之前我跟在 StrongLoop 裡面的貢獻核心代碼的了不起並充滿天賦的家伙聊過。他們正在明確的采用通過傾聽開發者對這個平台的回復，並且計劃找到修復這些問題去修復的正確方式讓未來的Node更加易於工作。我不確定多家公司對核心部分同時開發的沖突會如何結束，但我希望開發者驅動方會勝出。
這並不意味著這是一個對個人的攻擊，很多真的有天賦的人們正在與Node或在Node之上工作，但這再也不是我感興趣的地方了。我在Node社區中經歷了一段偉大時光的同時也遇到了一些真的很有趣的人。
故事的寓意在於，不要被你自己的圈子所限制住！看看其他地方有什麼，你也許會再次享受編程。在這之外還有很多了不起的解決方案，我犯的錯在於等了太久才去與他們一起游戲！