首先這是一篇翻譯自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社群中經歷了一段偉大時光的同時也遇到了一些真的很有趣的人。
故事的寓意在於，不要被自己的圈子所限制住！看看其他地方有什麼，你也許會再次享受程式設計。在這之外還有很多了不起的解決方案，我犯的錯在於等了太久才去跟他們一起遊戲！
