NodejsScalaClojure等聲稱適合高并發的語言？

先說一些共同點：

都試圖利用成熟的 JVM，并可以使用 JVM 平臺上現存的代碼和廣泛的庫，同時避免 Java 語言表達上的一些弱點。兩者都試圖將函數編程 (FP) 引入到原本是為純 OO 語言 Java 定制的 JVM 上。因此，它們都具有 FP 的特征：函數是頭等公民，可以作為參數傳遞，可以作為返回值返回。

但兩種語言的設計哲學截然不同：

Clojure 是歷史悠久的 Lisp 的一種方言，它需要尊重 Lisp 的傳統：包括臭名昭著（對 Lisp 愛好者是香味撲鼻）的括號海洋。當然 Clojure 做了很多不同傳統 Lisp 的處理，如引入了 Vector，map 等基本類型，而不只是 List。而 Scala 是全新設計的語法，它不受過往語法的限制；它深受 Haskell 的影響，有抽象數據類型 ADT、 模式匹配等鮮明特征。Scala 是強類型語言，編譯器積極檢查數據類型，有類型推斷等新類型語言的先進特征。Clojure 是鴨子類型語言，編譯器不檢查類型，這責任在于程序員自己（目前 core.typed 庫試圖把強類型檢查作為可選項加入到 Clojure 語言中，不過還遠遠不到成熟的地步）。Scala 認為 OO 和 FP 都是非常有效的表達方法，因此在語言中同時支持它們。Clojure 則強烈不鼓勵使用 OO 編程，盡管從與 Java 互通等方面出發有一些支持。它強烈傾向于 FP 編程。帶來的后果是 Scala 的程序風格可能會非常多樣，而 Clojure 則相對統一。Scala 是傳統的語言開發方式：有相當多的關鍵字和語法糖，都需要核心開發者支持。雖然加入了元編程能力，但其元編程與普通編程區別很大，難以被一般開發者使用。 Clojure 從 Lisp 處繼承的代碼即數據的核心，則保證了極為自然和強大的元編程能力，任何開發者都很容易用宏來定義自己的語法，因此基于 Clojure 定義自己的領域語言(DSL)非常容易。由于其多樣的語法特點，多種語義的支持，Scala 是一種相當復雜的語言，其語法的數量比 Java 語言還要多，更不要說其獨立于 Java 的自己的類型系統。與之相對，Clojure 的內核非常簡單，語法極為簡化。一個重要的后果是，Clojure 成熟較快，編譯器本身容易開發，而 Scala 的編譯器開發難度大得多。我本人是在評估了兩種語言的穩定性后做出的選擇。

兩種語言都是通用性的，因此是互相競爭關系，都聲稱自己適合全領域的編程。雖說在具體的庫支持上可能互有長短（比如 Clojure 的 STM 被認為是更容易進行并行編程，而 akka 這樣的 actor 庫可以讓 Scala 具有 Erlang 一般的能力），但這些很可能是臨時的。所以考慮到選擇一種新的語言，特別是如此有特點的兩種語言，需要做好顛覆三觀的準備（特別是少接觸 Lisp 的大多數程序員），然后根據自己的喜好進行選擇。

PS. 有人提出 Clojure 的可讀性不好，這點我非常不同意。這很可能是熟悉程度弱所帶來的一種偏見。對于自己不熟悉的語法表達會有這種看法。實際上，由于 Clojure 的語法統一程度強，一般來說好的 Clojure 程序的一致性會更好。當然，你也可以用它寫出很爛的完全不可讀的程序，但哪種語言也無法避免這樣的可能吧？

PPS. FP 與 OO 的編程邏輯截然不同，從 OO 為主轉為 FP 需要大的習慣轉變。但如果不進行這種轉變，何必學習一種新的語言來表達呢？特別是 Java 8 也已經加入了相當的 FP 支持，可以在 OO 為主的環境中加入 FP 的味道了。另外，Clojure 并不是純粹的 FP 語言，從實用性的角度上它支持相當多的可變性編程；更純粹的 FP 語言是 Haskell，學院派（非愛好者的“不實用”的說法）的語言。