回调烂透了
在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社区中经历了一段伟大时光的同时也遇到了一些真的很有趣的人。
故事的寓意在于，不要被你自己的圈子所限制住！看看其他地方有什么，你也许会再次享受编程。在这之外还有很多了不起的解决方案，我犯的错在于等了太久才去与他们一起游戏！
您可能感兴趣的文章: