一位Twitter工程師的Scala探秘之旅
原創
【51CTO精選譯文】本文的這個故事講述一個對編程語言有種近乎于宗教狂熱的Twitter工程師是如何投入Scala的懷抱的。一開始大量使用Ruby做為開發語言的Twitter曾遭遇過嚴重的性能問題，于是Twitter在尋找可擴展性強的替代語言的時候，找到了Scala。
大家好，我是al3x，一位編程語言的癮君子，哦不，是狂熱份子。我在工作中使用過Java，JavaScript，C，PHP，Perl，Ruby以及Python。出于興趣和愛，接觸過x86 Assembly，Erlang，Lua，Objective-C，Lisp家族，Haskell，以及C++。
我為Twitter工作。Twitter一直以來都大量使用Ruby。Ruby很好，但不是都好。Ruby VM低下的性能，monkeypatching（51CTO編者注：猴子補丁，也稱鴨子擊，指對動態語言運行時進行擴展或修改，而無須更改源代碼的一個方法），以及文化上的問題，在大型項目中的使用還是充滿疑問。我們要建造新的服務，感覺不想繼續用Ruby開發了。
對于Ruby的不滿，基本可以總結如下：
1）Ruby不太合適開發長時間運行(Long-Live)的服務器端程序，但JVM很合適，因為Java有10年的經驗教訓和優化，Scala是運行在JVM上的，所以天生就有了這個優點；
2) Ruby沒有很好的線程(Thread)支持，Ruby多線程會限制在一個CPU上（新的Ruby應該會改善這點吧）且Ruby VM的垃圾收集支持也沒有Java先進，就造成每個Ruby進程長時間運行后使用的內存月來越大；
3) 為什么不是JRuby? JRuby缺乏使用廣泛的Rem支持（很多優秀的Ruby包都需要C擴展，它們并沒有移植到Java），而且性能也不太理想，比MRI（C實現的Ruby VM）要慢
我心目中的系統語言白馬王子應該是：
◆快速
◆函數式
◆表達能力
◆靜態類型
◆并發
◆優美
◆輕量
我們列出的名單：C
C++
Python
Erlang
Java
JVM上的動態語言
結果沒一個滿意的。它們都有自己的問題。我們最終想要一個不是Java的JVM語言。
后來，我們聽說了Scala。在JVM上幾乎沒有哪個語言的執行速度趕得上它，而Scala lift-off看起來令人感到信心十足。
#p#
Scala的特性
不再糟糕的類型推斷。靜態類型一直是天使和惡魔的共存。在Scala中，在你真正使用它之前，你可以忽略對象的類型。
不變性：你可以在最開始用面向對象的方法編程，然后當你需要它的好處時，就可以遷移到用不變狀態(immutable state)。實現并發和異步就靠它了。這個功能需要在決策時更加深思熟慮，不過是值得的。
第一類函數：我們是“類”的追隨者。這是個有了就無法失去的功能：你不僅可以定義函數和調用它們，還可以把函數寫成沒有名字的文本：literal并把它們像值：value那樣傳遞。一切都是表達式，一切都有值。
特征：是個奇特的東西，因為繼承的未必是你想要的。一個類可以按照需要整合許多特征，這與接口相似，但它們還可包含行為，這又與類相似。同樣，與類和接口類似，特征可以引入新方法。
模式匹配與case類：其實每個程序員天天都在進行模式匹配。Scala不過是令這個過程更簡單了。
XML的處理大大的簡化了。再怎么說XML技術還在廣泛的使用中，使用Scala來處理XML文件是相當不錯的選擇：有點那么些JavaScript+JSON的意思。
Actors：處理并發的一個好方法。Scala提供的這個叫做Actor的并行模型通過它的收件箱來發送和接收非同步信息，而不是共享數據。這種方式被稱為：shared nothing 模型。一旦你不再顧慮共享數據的問題，也就不必再為代碼同步和死鎖問題而頭痛。
還有上面這些其他的特性，這里就不細說了。51CTO的編輯在此推薦大家去Scala編程語言專題中進行進一步的學習。
范例
最后，給大家看看我們在Twitter中用Scala編寫的代碼。
函數的使用：無論是array，類型系統，值還是Singleton的語法，都和Ruby一樣簡便。
Package，import，traits，currying，更多的類型系統。
當然了，Scala也有不好的地方，比如社區太小，而且也偏復雜。不過總的來說，Scala絕對是一門值得學習的語言。
原文：Why Scala?
【相關閱讀】
