
使用新語言的阻力
讓工程師從 A 語言轉換到 B 語言的成本中,最主要的是學習新語言花費的時間。工程師學習的時間越長,語言轉換的成本就越高,當然阻力也就越強。所以一般來說即便是新的程式語言,他在語法、特性不會跟既有程式語言相差太多,盡量降低學習門檻
另外一個成本會是社群的重新建立。當一個新的程式語言出來時,基本上不會有太多使用者,這樣在學習資源或是現成 Library 數量上就會少很多。舉個例子來說,假如今天一個 Rails 開發者要轉到 Goby,即便 Ruby->Goby 的學習成本不高,他還是得放棄 Rails 這方便的框架跟 Ruby 社群很豐富的 Library,這也會讓工程師卻步
使用新語言的拉力
然而世界上持續有新的程式語言出現,而且從舊語言到新語言的轉換也持續在發生(例如 Go),這又是為什麼呢?
主要原因是隨著科技發展,工程師們開發程式的平台及需求會一直變動,像是從 Web 時代轉換到 Mobile 時代。在這種情況下,新語言可以直接針對新平台、新需求進行設計優化以滿足工程師的需求;而相對新語言來說,舊語言因為通常太過龐大、且不太允許太大的 breaking change,所以可能無法或是需要一定時間才能支援新的需求(例如 Ruby 對 concurrency 的需求)。這時候開發者可能就會為了配合專案進度或是架構需求,而直接採用新語言來完成當前(甚至是以後)的任務
What about Goby?
我會持續開發 Goby 其實就是基於上面兩種假設:選擇 Ruby 的語法跟物件導向設計是為了盡可能降低學習門檻;而用 Go 寫則是要滿足現在 Web server 對於 performance 的需求(microservice 當紅)。只要 Goby 能夠帶來足夠多的效能提升,而且不會讓 Ruby 開發者太難上手,他們自然就容易轉換到 Goby,就像前陣子流行轉換到 Elixir 一樣
而 Goby 的另外一個機會是 Ruby 目前其實並沒有個成熟的 microservice 框架,再加上語言特性的關係,所以很少人會選擇用 Ruby 開發 microservice。因此在 microservice 的開發上,Ruby 工程師通常得選用其他語言,那跟 Go 比起來 Goby 可以節省許多學習時間以及有相對快的開發效率,所以應該是有一定程度的吸引力的
目前 Goby 已經可以做到直接呼叫 Go Plugin 的 function 或是 data,例如:
# p 為 plugin object
p = import "./plugins/plugin.go"
# 可以直接呼叫 plugin 的 top level function
bar, err = p.send("NewBar", "Foo") # 也可以呼叫 Go object/pointer 的 method
puts(bar.send("Name")) #=> "Foo"# 如果遇到型別轉換也不是問題
# Add 的 type 是 func(int, int64) int64 所以 100 要做型別轉換
r = bar.send("Add", 10, 100.to_int64)
puts(r) #=> 110
也就是說未來 Goby 開發者可以用 Go 寫 extension(應該是比 Ruby 的 C extension 好寫多了),寫完後再用 Goby 方便的語法進行操作。同時他們也可以 import Go 豐富的 library 到這些 extension 內,透過這種方式來讓他們的 Goby 程式使用 Go 的 library
以上幾點就是我目前還堅持全職開發 Goby 的原因,不過開發者們買不買單這些東西就要等第一次 release 跟 RubyKaigi 發表完才知道了
最後附上 Goby 連結,還不知道那是什麼的可以點進去看一下

