爲何 Node.js 這麼火,而一樣異步模式 Python 框架 Twisted 卻十幾年一直不溫不火?

twisted是一個強大的異步網絡框架,應用的面也很是廣,可是沒有這幾年纔出現的Node.js火,社區、文檔也是不多可憐
我以爲兩者其實在本質上差很少,並且python使用起來仍是比較容易一些的前端

匿名用戶

由於,它給了一大部分程序猿幻覺好比先後端統一,腳本也能性能很屌,作Demo搜搜快什麼的,但實際上,這僅僅是幻覺罷了……

正是由於這樣的幻覺是「看獲得」的,又有一個響噹噹的乾爹Google,所以Node的曝光率遠高於後端常規語言就不足爲奇了。

論速度,你一個帶JIT的跟常規腳本語言的虛擬機比,沒到數量級差別丟不丟臉?內存各類匪夷所思的佔用丟不丟臉?web才和CPython+Gevent一個水平比不過pypy丟不丟臉?
論穩定性,Python十來年的積累,大公司的經驗,你一個以桌面系統爲目標的V8拿來作工程逗我玩呢?
論代碼的管理,Js那種匪夷所思的陷阱還要不要一塊兒玩了?Callback hell?

說白了,前端工程師在普通level這級人數太多了,做出來的東西能看獲得,吸引力比埋頭在服務器上耕耘的系統工程師要高。技術新人每每是被看得見的先吸引到,但不深刻怎麼知道系統的嚴謹?node一出前者以爲本身各類碉堡,以爲System Engineer is die 而後四處宣傳,好比你看老子一天擼出個實時web,還帶個碉堡的前端實現,看看大家系統工程師,呵呵呵。Full Stack哦,一個socket鏈接消耗多少內存都算不出來你跟我談Full Stack?

因此,這就不是浮躁的宣傳這是什麼?系統工程是很嚴謹的,打交道的每每不只僅是代碼,最終產出最看重的也不是什麼性能,不少設計不少實現最終服務的都是後端系統的穩定性,擴展性等這些跟錢相關的東西,你跑來跟我談跑循環?循環能賺個錘子?

至於Python的XXX爲什麼不火,Callback早就有Twisted,新生代也有Tornado,Coroutine有Gevent,Actor有Pulsar,VM方面要穩妥CPython,要性能PYPY,要併發Stackless,AIO神馬的的選擇太多了,你喜歡上啥就有啥,社區要運做要宣傳怎麼鬧,手頭的牌太多了有木有。Node沒這樣的歷史包袱,就一個選擇,天然所有社區的力量和宣傳均可以集中到這上面去,加之低門檻,你看出書都出了多少,不火纔不科學。

可是,作工程和火不火有毛關係啊?node

bhuztez長期求職

關鍵是營銷作得好。說是由於Twisted有什麼不如Node.js的技術缺陷,那都是不客觀的。

好比python

Node解決這個問題靠的是強制異步IO操做,使得Event driven模型可以高效執行
這個就太想固然了。連node.js的做者都不會這麼說。你必定不知道什麼叫POSIX吧。按POSIX的定義,一個file descriptor假如對應的是普通文件,無論有任何non-blocking或者async的選項能夠設置,它必須block。Node.js也只是在背後開了一個線程池。這種作法和Twisted並無任何區別,並且比Twisted更糟糕。Twisted實現了線程池的功能,而且暴露API給你用,這樣你碰到別的無法異步的地方,你也能夠用Twisted的線程池。而Node.js在很長時間內並不打算提供線程池,或者說,Node.js有線程池只是你不會C++罷了。

另外,沒有搶佔式調度,你仍是不可避免地要審查代碼。有些代碼相比別的代碼消耗了太多CPU了,成爲了瓶頸。查這個比查有沒有調用會block的代碼可難多了。Python再沒節操,好歹庫裏也把語言自身的ast暴露出來了,很容易就能寫個腳本檢查出來了,現成Python代碼檢查工具不會比JavaScript難用的,JavaScript語言設計就拖後腿了。
緣由之一也許是 JS 能方便地在表達式裏插函數,你 python 的 lambda 裏能放語句麼?

只有要把同步寫法扭曲成異步寫的時候,lambda寫起來是否方便纔會顯得很重要。Twisted有inlineCallbacks,不須要扭曲。程序員

python這種語言要作nodejs的異步的事情,得語言支持cps變換才行

緣由是V8那時還遠沒有yield。就Node.js用沒有yield的V8而不用早就有yield的SpiderMonkey這點就能夠不用看了。這個選擇徹底就是爲了營銷。Python有yield,不必本身搞什麼CPS變換。web

tornado

是Tornado讓Twisted變得更好了。以前Twisted在Web方面沒有花太大精力,致使Twisted.web也就僅僅是能用,遠說不上是好用。可是Tornado除了Web部分作的比較好,其餘地方都是不如 Twisted的。只要把Tornado的Web部分移植到Twisted上,Twisted的Web也不爛了嘛。就有一個叫cyclone的項目作了這個。我不會告訴你跑分還比原生Tornado要好呢。

-----------------------------------------------------

在Node.js還沒起來的時候,Twisted那幾個開發者早就知道只能異步很很差,等知道有Erlang這種語言的時候,都開始大力向推薦你們用Erlang了。Node.js剛出來那時候和Erlang比,不,顯然就不應作這樣的比較。

營銷作得好,纔是Node.js火起來的關鍵。

假如你還記得那個多少行寫個IRC的slides。大體是這樣的,Node.js的做者在拿Event-driven和Apache那種fork子進程方式對比的時候,他是有理有據地指出了Event-driven的優勢。可是在講和其餘模式對比的時候,他講的是感受。他說要是把那些不能當即返回的操做的調用方式和通常的函數調用區別開,否則會給人以錯覺 。這樣一來,只能寫異步回調就當即變成優勢了。把Node.js最致命的缺點都包裝成優勢了,再沒節操地鼓動一幫人去搞一些毫無心義的benchmark,當即就避免了不利的局面。喊口號老是最容易的,事件驅動就是高性能, 庫就是包袱,異步回調地獄就是好就是好就是好。就火起來了。

就是這樣npm

劉縉系統編程

在Python增長帶返回值的yield前,Twisted代碼全是回調,程序結構那是至關的twisted。在Python這個注重代碼簡明的語言裏,Twisted實在是格格不入。大部分Python程序員恐怕沒看完deferred就被嚇跑了。

而回調對js程序員根本不是個事兒。編程

匿名用戶

首先對於排名第一大談 nodejs 弱爆了,System Engine 纔是吊的人作個冷嘲——真正作 nodejs 的若是不熟悉 v8 引擎和 libuv 其實只能是作做外圍吧?而熟悉 v8 和 libuv 的哪個沒有紮實的 System Engine 基礎(沒個七八年的 C/C++ 項目基礎能玩轉 v8 和 libuv 的那真是少見了)?而後說出什麼搞 nodejs 的人搞不清楚 websocket 消耗多少內存這種話你肯定打擊面沒有太大?難道你身邊有一些初級的 nodejs 開發人員給你形成了錯覺而後你就優越到沒邊了?後端

在這種角度就討論技術,討論的根本不是技術,而是本身的偏好,本身的圈子和好惡。調侃下能夠,可是真的是一點養分都沒有。而那些贊同他的人,我只想問大家真的有研究過 nodejs?服務器

分割線下面是以前的回答。websocket

-----------------------------------------------

 

說 nodejs 只是靠營銷的是否太天真了些?當初 nodejs 出來的時候各類 BUG,我簡單的測試其大文件傳輸都會出現各類問題。而同時期的其餘陣營早就甩其幾條街了。可是爲何卻能一直不斷髮展壯大?難道僅僅靠所謂的營銷和忽悠?

若是隻孤立的去考慮 nodejs 的異步庫到底怎樣怎樣,實在是太片面了,難道 nodejs 裏面就只提供了異步網絡 IO?

事實上,nodejs 是提供了一套通用的異步基礎設施,使得你能夠基於此構建各類異步 API。異步網絡 IO 只是其上的一個具體應用。而如今問題裏說起的 twisted 實際上在這一點上根本不具備與 nodejs 的可比性!

我選擇 nodejs 的緣由很大程度上是由於它是 JavaScript 的,這樣一來在先後端我能夠用同一種語言完成整個項目,這是極大的一個優點!另外,儘管 nodejs 不是惟一的也不是最先的基於 JavaScript 的服務端方案。可是它是同時期性能 JavaScript 陣營裏最佳的。

再加上 nodejs 底層的 libuv 設計很簡單,很是容易擴展,並且 npm 又那麼好用。所以開發效率急速上升。

選擇 nodejs 到底爲何,其實到了如今,許多人各自有各自的理由。但許多人都是由於他是基於 JavaScript 的低成本解決方案。

相關文章
相關標籤/搜索