Scala和Erlang，以及多核主導的未來
未來注定是多核的世界，問題在于如何去解決多核的危機。Scala和Erlang是兩門渴望成為其解決方案的語言，但它們也有些許的不同。那么它們所采取的方式各有什么利弊呢？
引入問題
摩爾定律已經改變了。我們不再獲得和以前一樣的時鐘頻率增長，取而代之，我們得到了更多的（CPU）核心。今天，也許你的筆記本都已經是雙核的了。
為了利用多核的特性，應用程序需要支持并發。如果你的客戶買了一臺八核的機器，要向他們解釋清楚正常情況下應用程序只會用到12%的CPU能力將是一件費時費力的事，即便該機器是為該應用量身定制的。
在未來，情況可能變得更糟。你的順序執行代碼不僅不會跑得更快，甚至有可能實際上跑得更慢。其原因在于，你獲得越多的核心，由于功耗和散熱的影響，每個核心就會更慢。幾年之后，英特爾就會給我們帶來32核的CPU，按這種趨勢，在我們不知不覺之中數千核的CPU就會出現。但每個核心都會比現在的核心慢很多。
并發代碼
一個顯見的解決途徑就是編寫（或重寫）軟件以支持并發。最常見的方式莫過于使用線程，但大多數開發者都認為基于線程的應用編寫起來特別的困難。死鎖，餓死以及競爭條件對大多數并發開發者來說都是太熟悉的概念了。Erlang和Scala都大大減輕了這種痛苦。
語言概覽
Scala常被看作是下一個主要的JVM語言。它結合了面向對象編程的范式和函數式編程的范式，與Java相比有著更簡潔的語法，它是靜態類型的，有著跟Java一樣或者有時候更快的運行速度。有太多的理由值得去認真探索一下Scala。
Erlang是一門為健壯性而生的語言，由于它的設計，它自然又是一門有著極好伸縮性的語言。它比Java歷史更早，但卻常被看作引領未來并發的語言。它是一門動態類型的函數式語言，有著一些非凡的系統正常運行時間的成功例子。
爭論核心
那么Scala與Erlang爭論的到底是什么呢？說到底，就是性能表現與伸縮能力，但這爭論也包括了其它像風格，語言特性以及庫支持等等。這場爭論開始于Ted Neward有一次無心的給出了他對幾種語言的看法，并稱“[Erlang]在其自己解釋器上運行事實上[是]很差的”。
Steve Vinoski與Ted于是展開了幾輪爭論，但這一討論很快轉移到了更多的博客上，爭論的焦點也轉變成了Scala與Erlang之間那些有趣的差異和共同點。我們將總結每個有意思的論點并給出每種語言的利弊，并表達對一些問題的各種不同看法。
可靠性
Steve Vinoski就Ted所發表的帖子進行了回應，給出了他對于“Erlang在其自己解釋器上運行”的感受：
事實上，Erlang在其自己解釋器上運行得，很好很強大；如若不然，不可能有如此好的可靠性，它將只是又一個面向并發的有趣但卻無用的語言實驗而已。
Steve談到這個問題，就算一個語言本身可靠，它所依賴的基礎也必須可靠才行。因為Erlang從骨子里就是為可靠性而設計的，從而支持并發，所以它不會受到一些并發性常見問題的影響，這主要是底層庫包在并發環境下運行很好。
另一方面，Scala是站在JVM之上的，所以一個重要賣點在于可潛在地使用所有現成的Java代碼。然而，大部分的Java代碼并非專為并發而設計的，使用Scala代碼時要將此考慮進去。
輕量級進程
要運行大規模并發應用，你需要大量的并行執行。這可以通過幾種方式達到。使用線程是一種常見的方式，使用進程又是另一種。其區別之處在于，線程與其它線程之間共享內存，而進程是相互獨立的。這意味著線程需要像互斥信號這樣的鎖機制，防止兩個線程在同一時間對同一內存進行操作，但進程不會受此問題影響，相反是使用一些消息傳遞機制來跟其它的進程間通信。但進程在性能和內存方面的代價是昂貴的，這正是人們就算知道基于線程的并發是一種極復雜的編程模型也寧愿選擇它的原因。
Steve Vinoski這樣寫到：
提供互不共享的輕量級進程架構將使得大規模并發能力變得十分容易，但這并不意味著一旦你設計好了，剩下的就只是編程的工作那么簡單。
Erlang采取了這樣的并發方式。一個Erlang進程是非常輕量化的，Erlang應用常常擁有成千上萬的線程甚至更多。
Scala通過基于事件的Actor從另一方面達到了同樣的效果。Yariv Sadan解釋說：
Scala有兩種類型的Actor：基于線程或是基于事件。基于線程的Actor在重量級的OS線程內部執行。它們從不相互阻塞，但每個VM上可伸縮的Actor不會多于幾千個?；谑录腁ctor是簡單的對象。它們是十分輕量化的，并且，像Erlang進程一樣，因此它們可以在一臺現代的機器上數以百萬計的產生。
Yariv解釋到，盡管如此，這里面也還是有一些區別的：
與Erlang進程的區別之處在于，每個OS線程內部，基于事件的Actor是順序執行的并且使用沒有強占式調度算法。這使得一個基于事件的Actor可能在很長一段時間內阻塞其OS線程（甚至是無限的）。
不可變性
Erlang是一門函數式語言。這意味著其數據是不可變的，像Java的String一樣，并且沒有副作用帶來的風險。對數據的任意操作會產生一個該數據新的修改后的版本，但原數據仍然不變。在談到健壯性的時候，不可變性是其需要高度注意的一個因素，因為沒有代碼可以無意間修改其它代碼依賴的數據，但從并發的觀點來看，不可變性也是一個十分重要的特性。如果數據不可變，其被兩個并行執行路徑更改的風險就不存在，因為沒有辦法改變它且不需要保持同步，所以數據可以被拷貝到其它機器上。
因為Scala構建在JVM之上，結合了面向對象和函數式方法的特點，它不具備像純函數式語言的不可變性的保證。然而，在Yariv日志的評論部分，Yariv和David Pollack就這兩門語言之間的差別展開了一場有趣的討論。David，Scala Web框架Lift的作者，給出了他對于不可變性的看法：
不可變性 —— Erlang強制了這一點，而且你幾乎無法繞過它。但是，與強制一個單一類型相比，你可以用Scala神奇強大的類型系統的剩余部分去交換。我在進行Scala Actor編碼時使用不可變數據，而讓Scala的類型系統負責其它類型。
Yariv問到：
只發送不可變類型難道不是一個重大限制嗎？這意味著，例如，你不能從Hibernate裝載一個簡單的bean并將它發送給其它Actor。
David回答到：
我曾基于Scala的Actor構建個多個生產系統。實際上對于不可變性問題并沒有多少工作需要處理。你只需要將你的相關類（消息）定義為不可變的，其它的就不用管了。
類型系統
Erlang是動態類型的，而Scala是靜態類型的并且相比Java有著更強的類型系統。然而，與Java相比最大的一個區別是Scala可以類型推斷。這意味著你可以省掉大部分的類型注解，使得代碼更加干凈而編譯器照樣會做所有的檢查。
關于動態與靜態系統之間孰是孰非的爭論看來永遠也不會停止，但Erlang和Scala之間卻有著顯而易見的區別。
尾遞歸或是循環
Yariv又提到：
函數式編程與遞歸從來都是形影不離的。實際上離開了尾遞歸你很難寫出有用的Erlang程序，那是因為Erlang沒有循環——它對一切都使用遞歸（這在我看來是一件好事 :））。
這顯然使得Erlang與Scala產生了很大差別。Scala提供了很多更傳統的迭代，但David Pollack并沒看出在這種環境下尾遞歸有什么優勢：
尾遞歸——對基于事件的Actor來說根本不是什么問題。
如此說來，這僅僅有關你的偏愛和風格罷了。
熱交換代碼
由于Erlang是為可靠性而生的，熱交換代碼（運行時替換代碼）是其內建的天性。
JVM對熱交換代碼有所支持。類可以被改變，但由于其靜態的類型系統，其方法簽名是不可改變的——只有其內容可以改變。雖然有第三方工具致力于此，也有框架（提倡以一種使運行時更方便交換類的編程風格書寫代碼），但就算運行在JVM上，如何進行交換仍是取決于你的Scala Actor是如何構建的。Jonas Bonér就此給出了一個詳盡的例子。
總結
Scala和Erlang都是致力于解決多核危機的語言。它們來自不同的背景和年代，因此對待某些問題的方式也不盡相同，然而在許多方面它們的共識大于分歧，至少在并發性上如此。
Erlang已經有著數十年的歷史，并且已經在許多關鍵的真實系統中證明了自己。其不足之處在于它有一點像一個孤島，最近的多語言編程的趨勢似乎對Erlang社區影響不大。
另一方面，Scala是同一類型應用的新生兒。一些真實應用即將誕生，并且一些公司將未來押在了上面。Scala相對Erlang的最大優勢在于，它運行在JVM之上并且可以利用所有現成Java代碼、框架和許多工具。話雖如此，這種強大的能力也要求了更大的責任，因為大部分Java代碼不可能自動適應Scala的Actor模型。
對于主流語言無法幫開發者解決的壓力越來越大的問題，兩種語言都對提供了相似的解決途徑。希望你在讀完這篇爭論總結之后，能更清楚哪種語言更適合你的特殊要求，并對其深入了解。
未來是多核的。Scala和Erlang將會越來越流行。
【編輯推薦】
