Express作者TJ告别Node.js奔向Go
首先这是一篇翻译自TJ的FarewellNode.js ，我本人在看完这这篇文章之后确实是受到了一些冲击，但我并不认同作者的某些看法，比如我认为Node.js的packageregister是其许多优势之一，反而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、bufferedIO、字符串操作等等。大部分的这些APIS都被定义的很好并且很强大。很容易仅仅通过使用这些标准库来书写整个程序。
第三方Gopackages
大部分的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:getaddrinfoEADDRINFO”，这个事实告诉我们Node的发展优先级在哪里。可理解的是，当你专注于建立系统核心的时候，会很容易漏掉这些东西。单我认为用户已经对这类事物一次又一次的表达了意见却没看到任何的结果。对于声称说我们拥有的已经是完美的，我们通常获得少数的回应。在实践中，却并非如此。
streams是被中断的,回调不容易使用，错误含糊不清，工具并不好用，社区条例是有，相对于Go而言却显得匮乏。尽管如此，一些特定的任务我仍可能继续去使用Node，比如创建网页，或者一些零散的API或者原型。如果Node可以修复一些它的基本问题，那么它有机会保持相关性，但当存在另一方案是更高的性能和更高的可用性的时候性能高于可用性的论证不会走的太远。
如果Node社区决定去拥抱generators并能在Node非常核心的地方实现他们，去适当的传递错误，是有机会让这个是可参照的。这会彻底的提高Node的可用性以及健壮性。
好消息是，不久之前我跟在StrongLoop 里面的贡献核心代码的了不起并充满天赋的家伙聊过。他们正在明确的采用通过倾听开发者对这个平台的回复，并且计划找到修复这些问题去修复的正确方式让未来的Node更加易于工作。我不确定多家公司对核心部分同时开发的冲突会如何结束，但我希望开发者驱动方会胜出。
这并不意味着这是一个对个人的攻击，很多真的有天赋的人们正在与Node或在Node之上工作，但这再也不是我感兴趣的地方了。我在Node社区中经历了一段伟大时光的同时也遇到了一些真的很有趣的人。
故事的寓意在于，不要被你自己的圈子所限制住！看看其他地方有什么，你也许会再次享受编程。在这之外还有很多了不起的解决方案，我犯的错在于等了太久才去与他们一起游戏！