node.js, and eventmachine.rb

雖然有點想寫成英文，不過我現在想省點時間，先速記一下。
日前寫了這篇 1638. 04-22 JavaScript 提到或許 JavaScript
是個可以值得投入時間去研究的東西，沒過多久，我想我需要
稍微修正一下這部份的想法。是的，我仍然認為那值得「觀察」，
但已不覺得真的值得投入時間去研究。諸多原因，容我娓娓不娓娓地道來。

先是又在 1680. 05-20 event-driven I/O 這篇中提到，我並不覺得
event-driven I/O 跟 language design 有很大的關係。如果只是
為了這件事的話，基本上拿 eventmachine 當做 framework 來用，
就可以做到所有 node.js 所做到的事情，如果 node.js 只是拿
V8 來做出一個 eventmachine 的架構。問題是，如果我們早已有
eventmachine 可以用了，那又何苦去使用 JavaScript 呢？

後來在 buzz 上有一點不愉快的爭論，我不知道這算不算是爭論，
我只是想釐清理解的角度而已。但綜合下來給我的感覺，再加上後來
聽了 Jaime 談了些 JavaScript 的東西，讓我只覺得 JavaScript
仍然是一個大便，而這跟 browser 什麼的倒沒有直接的關係。
翻翻 ECMAScript 的 specification, 仔細看看，還真的有把一團混亂
寫在 spec 裡面。是的也許寫得很清楚，並沒有什麼模糊之處，

但問題是或許這個 spec 是以解釋實作的角度，把實作寫成清晰的文字，
而非從頭設計一個語言，這樣的話，我總覺得並不是真的把問題解決了，
只是很簡單地減緩了問題造成的影響力而已。並不是說這樣的 spec 不好，
只是覺得這並沒有徹底解決問題。並不是標準化了，問題就會消失...
因為問題根本就不在沒有標準，有標準只能幫助實作減少混亂而已。

如果拿 JavaScript 是一個古老的語言，所以當然有這些遺產來護航，
這讓我覺得非常怪異。那我們為什麼不繼續用 Fortran..??
當然這跟到處是 javascript 的世界是不同的，
但我真的一點都不想繼續陷在泥沼或是焦油坑之中。
罷罷，我不想再陷入口水戰，我想我還得再多練習提早閉嘴，
還得對這樣的議題更敏感些，更早意會到已經多說無益了。

而在這之前，我也查到了這篇投影片：
EventMachine: scalable non-blocking i/o in ruby
這篇就是 eventmachine 作者的投影片，我只能說內容寫得比我好
太多太多了，如果在我做投影片之前有看到這篇的話，會很有幫助的。
裡面提到很多當時我還不是非常肯定的事情，而且讓我終於找到
eventmachine 架構下的 http client, 而不是使用 blocking i/o 的
net/http, 或是在其之上的 open-uri 和 rest-client.

我會找到這篇，正是因為我想找 eventmachine 架構下的 http client.
好笑的是，google 結果反而是先找到我自己的投影片 -_-
在 buzz 上稍微描述了一下這段。
...google "eventmachine concurrent network"

那時候覺得奇怪的是，em-http-request 似乎沒怎麼在發展了？
上一次的 commit 是很久以前的事了。而內建於 eventmachine 裡的
http client, 看起來也沒有 http multi-request 可以使用。
我在想，這麼重要，這麼必然的架構，為什麼會停止開發？
那時候真的覺得很失望。但前幾天終於看到了這篇，
發現 em-http-request 其實還在他自己的 repository 上開發，
（為什麼不在 eventmachine 下開發？？害我搞錯...）
也讓我正式開始覺得其實根本不需要去看 node.js

No Callbacks, No Threads & Ruby 1.9
async & co-operative web-servers

尤其是這幾句話還真是點出我的心聲：
"I'll take Ruby over JS"
"We can do better than node.js"

不過其實到這邊，我都還只是處於同意的部份，並不特別覺得怎麼樣。
繼續看下去到 em-­synchrony 的部份時，就開始有點傻眼，心裡開始
冒出一些 this is awesome, exciting 之類的句子...

雖然早就聽聞 fiber, 但卻從來不知道他是什麼，不知道他跟 thread
之間到底有什麼關係，wikipedia 上一大堆相關的東西，
又 light/heavy-weight thread/process/fiber, 光這樣看根本就搞不清楚...

先把話題帶回 event-driven 的架構下。雖然我覺得這樣的架構，
在學習之後可以是很自然直接直覺的作法，但似乎對很多人來說？？
這樣的架構是難以理解，而且不方便使用的。這也是上面那篇，
我不同意的那篇所提出的論點之一。他說因為 ruby 的 library 大多
都不是 event-driven, 因此會很難做出 event-driven 的東西，
很多 library 實際上都需要重新寫過。反之 javascript 則因為嵌在
browser 裡面，具有一部份 GUI 的天性，因此很自然會是 event-driven,
也因此大多的 library 對此點會有警覺性。

對我來說，這根本就不是問題。其他人要怎麼亂寫，關我們會寫的人什麼事？
要這樣說的話，拿 javascript 亂寫的人不是更多？ XD
anyway, 如果這是一個問題的話，我確實同意 event-driven 的架構
門檻是比較高，可能會的人比較少一點。而 em-­synchrony 就是
拿來解決這個問題的 library. 他讓你寫看起來是 synchronized 的程式，
但實際上還是以 event-driven 的架構在跑，而這就是靠 ruby 1.9 的
fiber 來做 continuation, 讓程式可以寫得就像是原本的 blocking 程式。

我到現在還是不太懂 continuation, 尤其是背後的理論，之前聽了一些
覺得很難懂.. 或是說跟 concurrency 扯上關係的東西，大多都很難。
其實在 ruby 1.8 就有這樣的東西了，就是 callcc, 雖然不好懂，
但只是要用的話也還好。但這樣東西最後被拿掉了！在 1.9 裡看不到。
並不是因為 continuation 不好，而是因為 callcc 在 1.8 的實作，
效能非常非常的差，差到幾乎不能在重要的程式裡面使用，
而且對於 1.9 的 YARV 而言，似乎也不能使用這樣的實作方式？
就不知道是否有可能用 fiber 做出 callcc 了，總之沒有 callcc 了。

我還沒有實際試過 em-­synchrony, 但至少他的理論看起來是可行的，
更厲害的是，這件事或許可以做成 library, 因此對 library 使用者而言，
這樣 event-driven 的架構有可能變成透明的。

在投影片的最後，作者則提到或許 Rails 3, Ruby 1.9, 這樣 evented 的
架構，任何一個都不足以說服人把所有程式搬過來。但三者加在一起，
就足夠是一個夠大的轉換理由。

why Rails 3?
因為 Rails 2 似乎根本不能跑成 event-driven 的方式。
我之前在上面試 thin 的 async.callback 死得好慘啊。
明明就已經設定成 thread-safe 了（實際上並不真的需要），
他居然還有個莫名其妙的 lock, 導致 deadlock, 跑不了 async.callback.

說真的，rails 2 越深入使用，我就越覺得爛... 儘管我是看到了
真的能夠把 rails 2 用得很好的狀況，不會去碰到內部糾結的問題。
但有太多先進的東西，因為其內部的實作，根本就無法使用。

也因此，我一直懶得去看 rails 3, 因為狼來了 XDDD
更寧可直接在 rack 上試，或是用 ramaze/innate 或 sinatra.
也可能是因為其實我對 "application" 本身的興趣，
遠遠小於對 library 與 framework 的興趣吧。

作者 Ilya Grigorik 的網站上也能看到很多資料，我都還沒細看，
我想可以找機會翻翻看，相關的東西還不少，可以慢慢看。
雖然他把 unicorn 跟 passenger 看成同一件事，不過我覺得不太一樣，
因為 unicorn 本身是非常單純的，而且其實並不一定是 I/O bound,
也可能是 CPU bound, 這種時候 evented I/O 的架構並不能解決問題，
而這樣的架構，事實上是由 rainbows 在解決的，unicorn 是核心，
並沒有觸及到那樣層級的架構。所以這部份我認為是，對也不對。
不要去看 rainbows 的話是對的，考量到 rainbows 的話就不是很正確了。