如何看待 TJ 宣布退出 Node.js 開發，轉向 Go？

11-26

參見: Farewell Node.js

蟹妖。

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在將來會是前後端分工的分界線。

TJ是個理性的工程師，語言只是工具，什麼工具幹什麼事情，他在告別node的文章中也說了，如果web開發他還是會用node，只不過現在他要轉向分散式系統的開發了，所以選擇了更加適合的工具golang，這沒有什麼好奇怪的啊，如果你老闆現在突然讓你做嵌入式開發你能不轉c和彙編嗎？

我本來自己寫了個基於lua協程調度的並發庫levent（https://github.com/xjdrew/levent），後來用go越來越順手，感覺levent的價值不太大，就慢慢停更了。這哥們會不會和我一樣想法？

再放個大招。nodejs用非同步回調並發，比協程醜陋不是一星半點。可能存在的唯一理由就是v8引擎的強大了。。。

TJ文章開頭說了，他在nodejs方面做很久了，沒激情了，並且最近在做的分散式系統讓他覺得Go更合適，所以他發一遍文章正式告別nodejs社區，順便找有興趣維護他原先項目的人。

我跑他主頁逛了逛（Tj Holowaychuk），照片拍得很棒，另外頭像很殺馬特。。。從哪個角度看，這個小夥子都是個比較感性，比較完美主義的人。會因為激情和審美的原因換語言再正常不過了吧。

小夥子不止長得帥，技術還那麼牛，攝影也那麼棒，不得不感嘆：這人和人的差距咋就那麼大哩？

我是從強類型靜態語言（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 這樣的生產力井噴效果。

仔細看看他的博客，寫的很清楚了。他的興趣是在分散式計算上，這個領域用Go當然是最合適不過，他還會繼續維護koajs，其他項目則在找人接手。
提到了一些nodejs的缺點，易用性，工具、debug、錯誤信息，這些都是nodejs客觀存在的問題，JS語言的先天不足在服務端語境中被放大了。
當年mogorel的作者Zed Shaw謾罵式地宣布脫離ruby圈子轉投python，這兄弟表現得夠理智了，純粹是由於技術選擇，而不是出於厭惡社區的自滿（當然也有一些對joyent團隊不聚焦到易用性上的不滿）。
我覺得不必過於放大事情的影響，但可以讓nodejs粉絲們更加客觀一點，給nodejs做出更準確的定位，那就是好事。

技術選擇，一定不能「哪個牛逼用哪個」，也不能「哪個時髦用哪個」，更不能「牛人用哪個我就用哪個」。

技術選擇，要根據自身團隊的特點，加所要開發產品的特點來做判斷。

我現在的團地使用的是Node.js，之前用的是PHP前端+Python後端，那時候一個大問題就是團隊沒幾個人，還有好幾個語言在使用，當Python部分出問題的時候，其他不擅長Python的隊員也幫不上啥忙，當PHP任務比較吃緊時，Python隊員又不能雪中送炭，所以那時候就計劃把使用的語言和使用的存儲方式縮小到盡量小的範圍，所以有意訓練組員的JavaScript能力，因為JavaScript怎麼著大家都要會一點。

當新的產品要開發的時候，發現這個產品明確需要有Server Push的功能，用PHP那一套肯定搞不定了，所以就趁著一個新的開始，全轉到Node.js上，這樣大家都能專心做一門技術，互相之間也能夠有照應。

事實證明，這個選擇是正確的。

雖然Node.js有這樣那樣的缺陷，其他同志所得Callback Hell之類的問題，只要有async、Seq之類工具的輔助，藉助良好的單元測試習慣大面積覆蓋代碼測試，最後寫出來的代碼質量很高。

還是那句話：會寫代碼的人，用什麼語言都能寫好；不會寫代碼的人，才會糾結於用什麼語言更好。

謝不願意透露姓名的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，都是更好的選擇。

雖然,我想寫代碼寫到萬萬歲,
但是,我覺得我也不會幹一輩子程序員的.

tj在segment上班，segment轉向go，就這麼簡單....

另外看到前面那個package排名也太古老一些了吧。。。

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 語言設計當中對語法, 對性能, 對開發調試的考慮, 都顯得周到得多
當存在這樣一門語言時, 怎樣選擇來提高開發的效率, 顯得比較清晰了

本來
nodejs就適合寫邏輯簡單高實時的場景
java scala c＃ c++ go適合邏輯複雜高實時的場景

不衝突

一大批Node粉要轉Go了

現在是動態語言一生黑，js缺點前面各位也說了，調試困難調試困難調試困難調試困難調試困難！！！
前後端統一語言沒看到什麼優點和必要性，在大公司有各種語言實現的基礎設施，單node玩不轉。甚至go也不好用，現在幹活都是在寫業務邏輯，用node/go節省不了什麼時間，而且那麼多周邊設施:db proxy /cache service/其他部門外部介面，挨個移植到node、go直至好用實在不容易.非同步callback太難用啦，想想要為每個業務寫回調函數就覺得累，邏輯被拆得支離破碎導致閱讀困難，代碼量更大，RPC才是王道喲。

node.js 最大的優勢是並發處理能力，不過這個是通過非同步方式來達到的，非同步方式非常不適合大腦思考，同步模式下簡單的邏輯用非同步模式來寫也要很複雜的代碼。go 提供了相同並發性能的同時卻可以讓程序員以同步方式編寫代碼。除了遺留系統和學習成本以外實在想不到還繼續用 node.js 的理由。

JavaScript這個語言設計上的缺陷頗多，並不是最佳的非同步服務端編程語言。
前後端統一是個虛幻的優點。實際上前後端的領域知識差異很大，強求統一語言沒有必要，就像你不會用C++來寫動態頁面一樣。
NodeJS能火，Google的V8功不可沒，有乾爹就是不一樣，想想JavaScript引擎這些年的進步吧。不過Go也是Google的產品，一樣有乾爹光環。

--------------------------------------2014年7月5日更新--------------------------------------------------------------
前後統一，當時提出來的時候我就非常訝異。難道用JavaScript來寫後端，就解決現在後端開發的問題了？難道讓JavaScript程序員涉及後端，就能降低開發成本？事實是JavaScript並沒有什麼優勢，而且JavaScript程序員的整體水平是比較低的，他們大部分人並不勝任。能用JavaScript在前後端遊刃有餘的都是牛人，而牛人用其它語言也能幹得一樣甚至更好，比如投奔Go的這位。

來更新一下最新消息，TJ最終沒有退出Nodejs世界。他只是在寫系統的時候換用go，koa框架依然在維護、在更新、在貢獻。而且基於es7的koa v2正在快馬加鞭，他參與的還挺頻繁的。同時，他發布的go項目目前缺乏亮點，沒什麼人關注。

我們的需求，和 TJ很像，也是同時要做網站，又要寫系統。於是有個深有體會：nodejs 和 go 缺一不可，根本做不到告別一個世界，只用另一個。所以那個道別的twitter直接當一時興起的玩笑就好了。

nodejs和go互不能代替在於：
1. go是個強類型語言，不支持未定義結構的Json。
而網路傳輸，以及網路常用nosql資料庫，全都是原生支持Json，從前端到資料庫，一路json到底。這太方便了，如果用go，必須一個個定義結構，要累很多很多，靈活性太低，真的是活活把自己累死。用Nodejs，高效很多倍。

而且，國外性能測試，網路開發的常規操作：資料庫添刪改查、響應http，性能上nodejs和go是幾乎完全一樣的。go的性能優勢在系統方面。

2. go在寫系統方面，完勝nodejs，根本就沒可能用nodejs去寫。除了性能比nodejs高之外，go在系統方面的開源庫，也比nodejs多。於是，你只能用go，不能用nodejs。

go的語法設計有一些彆扭的地方，用的時候，要長期忍受很多問題。就語言本身，其實是沒有基於es7的nodejs用的舒服的。但是，寫系統時，為了性能啥的，只能忍了。

在我們看來，基於es7的nodejs，就是一個超級方便的go語言，唯獨它只支持單核，於是弄系統只好用go

tj是短跑高手。過段時間go玩膩了他會玩別的。
如果你是創業CTO，不要學他，因為創業是馬拉松，不是短跑。

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 社區能繼續貢獻優質代碼和庫~

怎麼不去投奔Yin語言？納悶。