如何看待 TJ 宣布退出 Node.js 开发,转向 Go?

langsim · · 14160 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

TJ何许人也?

他medium自我介绍:TJ Holowaychuk,程序员兼艺术家,Koa、Co、Express、jade、mocha、node-canvas、commander.js等知名开源项目的创建和贡献者。

社区影响:

https://nodejsmodules.org 第一页出现次数最多的那个少年
Quora: How is TJ Holowaychuk so insanely productive? —高产到令人发指,Quora上甚至有人猜测TJ不是一个人,而事实上他就是一个人。
substack/npmtop:对node npm社区代码贡献截止目前占到整个社区的3.04%
rank   percent   packages   author
----   -------   --------   ------
#  1    3.04 %      28      tjholowaychuk
#  2    2.82 %      26      samuraijack
#  3    2.28 %      21      gozala
#  4    1.95 %      18      creationix
#  5    1.85 %      17      isaacs
#  6    1.74 %      16      substack
#  7    1.63 %      15      kriskowal
#  8    1.52 %      14      marak
#  9    1.41 %      13      coolaj86
#  9    1.41 %      13      pkrumins
# 11    1.19 %      11      masylum
# 12    1.09 %      10      TooTallNate
# 13    0.98 %       9      cloudhead
# 13    0.98 %       9      davglass
# 13    0.98 %       9      indexzero


个人对他的印象:TJ大神、visionmedia、潮男、酷炫、杀马特

TJ绝对是这一两年node社区的“弄潮儿”+“精神领袖”。
引用一个知友的话说,
任何一个做node.js开发的人, 一定都直接或间接引用过他写的库。这里说的是任何, everyone! 
他写一个co, 立马就会有无数叫co-*的项目出现。
他写一个koa, 立马就会有无数叫koa-*的项目出现。

他从npm社区诞生之初就开发了commander.js、node-canvas等著名模块。

随后他又开发了Express.js、jade、EJS等web开发系列框架和库。

最近一段时间,他把精力放在了运用ES6特性解决javascript回调金字塔的问题的Co库和下一代node web开发框架koa,而这两个模块虽然目前知名度不如express.js,但未来会是红得发紫的技术。

他创建并参与的开源项目实在是太多,以至于随便在他github上找个仓库, 就有上千上万的stars。

最近随着我在工作中无意得知并使用了co和koa来进行开发web后端开发,越发觉得这位TJ大神真是node社区的明灯,这一两年他在我心目中的地位逐渐上升甚至超过了node核心开发团队,相信很多人内心都有相同的感受

他在博客上的告别文章,并不意味着他当即完全告别node开发,co和koa这俩大有前途的框架仍会继续维护,其他的项目会转交给别人维护(言外之意要将其他烂摊子全部丢掉?)。

在他的文中,他提到node不再适合当下他开发的软件了,并且他选择了Go:
If you’re doing distributed work then you’ll find Go’s expressive concurrency primitives very helpful. We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there. Without separate stacks error handling & reporting will be mediocre at best. I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.

Go有表现力的原生并发特性对开发分布式任务非常有效,即便是ES6引入的generator也只能满足他一半的需求,node并没有独立的错误处理栈。TJ接下来因为工作需要,要从事分布式软件的开发,显然Go是更合适的选择。

错误处理一直是是JS遗留的比较深的坑了,需要一些时间来填。TJ不愿意花3年的时间等待node社区将坑全部填了,或许还表达出他对node社区和核心开发团队的些许“不满”

个人认为,稳定、高性能、分布式的纯后台开发,例如交易系统,Go、Java和C++是更佳选择,尤其是专为分布式设计的Go,只是当下人才还比较少;
对于主要处理前台展现的web工程,node是不错的选择,毕竟性能也尚可,前端工程师可以“前后通吃”,还是看好node在将来会是前后端分工的分界线

xj drew程序员,最近在学习IOS开发

我本来自己写了个基于lua协程调度的并发库levent(github.com/xjdrew/leven),后来用go越来越顺手,感觉levent的价值不太大,就慢慢停更了。这哥们会不会和我一样想法?

再放个大招。nodejs用异步回调并发,比协程丑陋不是一星半点。可能存在的唯一理由就是v8引擎的强大了。。。

沈嵘产品总监

知乎用户、陈天旭李延伟 等人赞同
我是从强类型静态语言(15年)转到 Node.js + JS 这种动态语言的(3年)。而 TJ 是从动态语言(Flash 的 ActionScript 起步)转到 Go的。可以说两个世界各有自己的优缺点。

Node.js + JS 可以说是用来包容各种可能性的。我用的时候是从照搬之前的OO概念,到后来的函数式编程,流编程(应该算一种特殊的函数式编程),发现世界上的问题真的是没有最优解。每年都能在 node.js 社区发现全新的颠覆思维惯性的新可能。例如,编写真正前后端复用的代码,然后通过 Browserify 在客户端复用;通过 Stream 来连接各个应用组件;基于 LevelDB 构建自己的数据库。

Callback Hell 我通过以下几个方面克服:

1. CoffeeScript:从视觉上减少嵌套干扰。
2. npm 哲学,将你的代码抽象出尽量小的重用部分,单元测试覆盖,分而治之。
3. 新的连接架构,例如: stream,或者类似 express 的插件机制

大约1年后,我就不觉得这是一个困扰了,而收获却是性能。目前,回调逻辑比任何其他方法都能确保并发性能。这一点 TJ 提到了,你是要“performance” 还是"usability",他的选择是“usability”,毕竟他是从 JS 走向强类型,而不是反过来的。

但是不得不说,越多的可能性对开发者的素质要求越高。如果团队成员中缺少那些“真正的老兵”,那么我会选择类似于 Go、Java 或者 .NET 这种强类型系统,毕竟可以有紧密的编程范式来约束大家,省得犯低级错误。

谁都没想到,JS的成就其实来自于自身的缺陷(非常松散的语法),各种软件方法学都在这里碰撞。这和 Go 是完全不同的。

另外, Go 包管理由于不支持 Side-by-side 的包引用(算是静态语言的一种限制吧),因此很难让 Go Package 社区(无论是否有集中存储) 形成像 npm module 这样的生产力井喷效果。

知乎用户,前端工程师

TJ是个理性的工程师,语言只是工具,什么工具干什么事情,他在告别node的文章中也说了,如果web开发他还是会用node,只不过现在他要转向分布式系统的开发了,所以选择了更加适合的工具golang,这没有什么好奇怪的啊,如果你老板现在突然让你做嵌入式开发你能不转c和汇编吗?

宝术1688.com 阿里巴巴2015春季…

知乎用户、电老虎Robin Yao 等人赞同
仔细看看他的博客,写的很清楚了。他的兴趣是在分布式计算上,这个领域用Go当然是最合适不过,他还会继续维护koajs,其他项目则在找人接手。
提到了一些nodejs的缺点,易用性,工具、debug、错误信息,这些都是nodejs客观存在的问题,JS语言的先天不足在服务端语境中被放大了。
当年mogorel的作者Zed Shaw谩骂式地宣布脱离ruby圈子转投python,这兄弟表现得够理智了,纯粹是由于技术选择,而不是出于厌恶社区的自满(当然也有一些对joyent团队不聚焦到易用性上的不满)。
我觉得不必过于放大事情的影响,但可以让nodejs粉丝们更加客观一点,给nodejs做出更准确的定位,那就是好事。

彭哲夫只是……一个好人……

知乎用户、戴明明史塔克 等人赞同
谢不愿意透露姓名的UC前端号称第二强的 @刘洋人肉邀请……

虽然语言只是工具,但是对于做的事而言,正确的“工具”往往会达到事半功倍的效果。在这一点上我一直认为,前后端统一也就是个笑话。

即便不说JS语言层面上的天生弊端,比如过于灵活以至于混乱的语法带来的工程上维护成本的巨大,V8本身的稳定性对于后端而言就是个巨大的挑战。Google V8起源于Chome,追求速度,以空间换时间的做法在当前大内存时代并不那么硬伤,稳定性稍差也不是什么很致命的事。但是在服务器上,一寸内存一寸血,谁都不像OOM以至于Crash。速度快慢也没那么重要,服务端追求扩展性,在数百数千甚至数万这个量级上单台服务器极致性能往往没那么重要。在这个基础上,稳定性和可用性最终决定了你服务质量,而这些,都是目前V8或者说node的短板。

同时,服务端要求对所用的技术有足够的可控性,node或者说js大量的black magic削弱了系统工程师在这方面对其的信任,出了问题没办法调,找不出bug,downtime上升,谁负责?

为何Java被人喷死板依旧占据了那么大的份额?为何C那么老依旧是服务端程序猿的基础?为何Python慢成狗还是有很多公司青睐?无他,只是因为他们经过了大量的考验,证明是可靠的并且可控的罢了。况且即便是Python,最新一系列技术加持之后,对比Node还真不慢……

至于为何转向Go?我个人认为Go抓牢了服务端开发的几个大需求,首先是抹平服务器差异,俗称跨平台。然后是标准库做得很相对而言很强大,系统细节屏蔽得很不错。再者是语言层面即满足了脚本小子们所需要的动态性和开发效率,也满足了系统工程师的静态需求来维持项目的有序性和最终输出结果的效率。同时对于未来服务端开发趋势的迎合,比如原生Coroutine并且极力的优化其内存消耗等特性,对于服务端开发而言是极大的提高了生产力的同时也让代码逻辑和可读性大大的提升。基于以上几点,Go确实是当下作为性能型服务端开发语言中比较好的选择。

而Node的核心V8,作为一个桌面项目,在这些方面缺陷太过于明显。做demo不错,上到工程级别就WTF了,至少对于我来说,lua/python/go,甚至是未来的rust,都是更好的选择。

达达服务端程序员,主页:1234n.com

知乎用户、David Chang 赞同
TJ文章开头说了,他在nodejs方面做很久了,没激情了,并且最近在做的分布式系统让他觉得Go更合适,所以他发一遍文章正式告别nodejs社区,顺便找有兴趣维护他原先项目的人。

我跑他主页逛了逛(Tj Holowaychuk),照片拍得很棒,另外头像很杀马特。。。从哪个角度看,这个小伙子都是个比较感性,比较完美主义的人。会因为激情和审美的原因换语言再正常不过了吧。

小伙子不止长得帅,技术还那么牛,摄影也那么棒,不得不感叹:这人和人的差距咋就那么大哩?

张明锋高级系统工程师,开源系统,软件,优化,…

飞书Joe知乎用户、彭灵波 等人赞同
我就纳闷了为什么同样Python twisted也是异步处理就没有大多数技术人员推。好了么,诚如我之前面试时候回答的那样,node.js的callback巨坑而且非coroutine方式处理。我如果需要并行处理的话直接会选择golang连python gevent都不会考虑。

知乎用户,linux后端

知乎用户、韩梅梅姜天意 赞同

现在是动态语言一生黑,js缺点前面各位也说了,调试困难调试困难调试困难调试困难调试困难!!!
前后端统一语言没看到什么优点和必要性,在大公司有各种语言实现的基础设施,单node玩不转。甚至go也不好用,现在干活都是在写业务逻辑,用node/go节省不了什么时间,而且那么多周边设施:db proxy /cache service/其他部门外部接口,挨个移植到node、go直至好用实在不容易.

异步callback太难用啦,想想要为每个业务写回调函数就觉得累,逻辑被拆得支离破碎导致阅读困难,代码量更大,RPC才是王道哟。

题叶我在学 CoffeeScript

知乎用户、陶铖宋方睿 赞同
Node 是 JavaScript the good parts,Go 是着眼设计一门替代性的编程语言,坑多没办法。
对前端和 Web 来说 Node 极好,Node 流行主要因此。而这不代表 JavaScript 就是很好的。
Go 对于动态语言用户来说相当友好。

不了解 TJ, 作为一个不会 Java 的前端, 我学习编程过程中用了大量 TJ 写的工具,
比如 Stylus, Debug, Jade, Express, EJS, 相信很多人也是
TJ 据传有超高的生产力, 这种东西是我们非常向往的, 我个人也很渴望有那样能力,
当然我有同样的追求工具高效的想法, 不代表能了解 TJ 其他的想法...
我很早就想摆脱 JS 动态语言, 用静态类型编程, 却一直不成, 直到 Go 进入视野
Go 语言有 Slice 类型, 操作近似 Array, 有 Map 类型, 形似 JavaScript 中 Object 的使用,
另外 Go 也支持函数式的闭包, 自动垃圾回收等等, 这对于开发效率来说很好

我渐渐有想, 动态语言究竟为何流行起来的, 出来易学, 有那样多的缺陷,
首先是随意被人吐槽的性能问题, 到了 JavaScript 特别又指出弱类型的调试问题,
甚至 JavaScript 语法当中大量的设计糟糕的语法也常常被作为嘲笑的对象,
Google 设想替代 JavaScript 的 Dart, 采用的是可选的静态类型, 还有无视了原型继承
我想 JavaScript 除了意外的成功, 也因为支持函数式特性, 以及灵活的 JSON 结构
而这并不是因为 JavaScript 设计得足够好, 这些特性在 Go 里面依然能做到支持

实际中的 JavaScript 编程, 会有大量的学习时间消耗在学会避免写出低质量的代码
比如随意定义全局变量或者类型构造器属性, 处理分号, 采用恰当的类的实现等等
甚至有将比如从 CoffeeScript 语言编译到 JavaScript 来保证采用的是好的编程风格
当我们写 Node 程序, 依然少不了手动避开语言差的部分, 尽量保持代码清晰
但这样我们仍然受到 JavaScript 弱类型等特性的影响, 而没有强大的类型检查工具

JavaScript 社区, 有大量的水平参差不一的前端后端工程师, 观念上也大量不能统一
后端的开发语言要跟着前端浏览器的实现走, 语法上的问题也不能够随意剔除
我个人觉得存在上述问题, JavaScript 社区的未来已经够令人担忧了
相比之下, Go 语言设计当中对语法, 对性能, 对开发调试的考虑, 都显得周到得多
当存在这样一门语言时, 怎样选择来提高开发的效率, 显得比较清晰了

程墨Morgan互联网产品开发者

技术选择,一定不能“哪个牛逼用哪个”,也不能“哪个时髦用哪个”,更不能“牛人用哪个我就用哪个”。

技术选择,要根据自身团队的特点,加所要开发产品的特点来做判断。

我现在的团地使用的是Node.js,之前用的是PHP前端+Python后端,那时候一个大问题就是团队没几个人,还有好几个语言在使用,当Python部分出问题的时候,其他不擅长Python的队员也帮不上啥忙,当PHP任务比较吃紧时,Python队员又不能雪中送炭,所以那时候就计划把使用的语言和使用的存储方式缩小到尽量小的范围,所以有意训练组员的JavaScript能力,因为JavaScript怎么着大家都要会一点。

当新的产品要开发的时候,发现这个产品明确需要有Server Push的功能,用PHP那一套肯定搞不定了,所以就趁着一个新的开始,全转到Node.js上,这样大家都能专心做一门技术,互相之间也能够有照应。

事实证明,这个选择是正确的。

虽然Node.js有这样那样的缺陷,其他同志所得Callback Hell之类的问题,只要有async、Seq之类工具的辅助,借助良好的单元测试习惯大面积覆盖代码测试,最后写出来的代码质量很高。

还是那句话:会写代码的人,用什么语言都能写好;不会写代码的人,才会纠结于用什么语言更好。

阿哲多年RIA开发

知乎用户、蒙乐兴钟睿 等人赞同
  • JavaScript这个语言设计上的缺陷颇多,并不是最佳的异步服务端编程语言。
  • 前后端统一是个虚幻的优点。实际上前后端的领域知识差异很大,强求统一语言没有必要,就像你不会用C++来写动态页面一样。
  • NodeJS能火,Google的V8功不可没,有干爹就是不一样,想想JavaScript引擎这些年的进步吧。不过Go也是Google的产品,一样有干爹光环。
--------------------------------------2014年7月5日更新--------------------------------------------------------------
前后统一,当时提出来的时候我就非常讶异。难道用JavaScript来写后端,就解决现在后端开发的问题了?难道让JavaScript程序员涉及后端,就能降低开发成本?事实是JavaScript并没有什么优势,而且JavaScript程序员的整体水平是比较低的,他们大部分人并不胜任。能用JavaScript在前后端游刃有余的都是牛人,而牛人用其它语言也能干得一样甚至更好,比如投奔Go的这位。
一大批Node粉要转Go了

刘典架构师,程序员,摄影爱好者,潜水爱好者

node.js 最大的优势是并发处理能力,不过这个是通过异步方式来达到的,异步方式非常不适合大脑思考,同步模式下简单的逻辑用异步模式来写也要很复杂的代码。go 提供了相同并发性能的同时却可以让程序员以同步方式编写代码。除了遗留系统和学习成本以外实在想不到还继续用 node.js 的理由。
知乎用户、liu威kiisun 赞同
我只在一个项目中用NodeJS做过服务器,异步编程有的时候真的让人抓心挠肝,TJ向Joyent提出的建议其实每个Node开发者都有感触。

NodeJS开发的易用性上有两点让人特别痛苦:

1. 各种回调方法使得代码非常难以调试;
2. 如果没有一个比较良好的设计,代码乱得一塌糊涂。

但是从目前的发展状况来看,Go语言比较只是Google一家做出贡献,跟Swift、Object C差不多,真正想要像JavaScript一样得到各家公司的认可还需要更多的努力。

微软、Intel还有几家互联网巨头,明显向JavaScript已经抛出了橄榄枝。所以我的观点是:NodeJS只可能越来越好,易用性上社区会注意到,也会不断改善。

more progressive一点的话,Node最好的情形能够像Java一样运行于各类服务器中,最差的可能也就是像python一样,成为在某个方向上的利器。

知乎用户,百度前端攻城狮。

郑少鹏 赞同
虽然,我想写代码写到万万岁,
但是,我觉得我也不会干一辈子程序员的.

匿名用户

说真的,TJ没有考虑Scala嘛?

张晨爱好网页开发和 Python

TJ 说“I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.”

结果现在 Node 社区不但没有 "defragment" 反而 fork 出来了 io.js 。。。

希望大神在 Go 社区能继续贡献优质代码和库~

有疑问加站长微信联系(非本文作者)

本文来自:CSDN博客

感谢作者:langsim

查看原文:如何看待 TJ 宣布退出 Node.js 开发,转向 Go?

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

14160 次点击  ∙  1 赞  
加入收藏 微博
2 回复  |  直到 2000-01-01 00:00:00
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传