來源：36氪
這篇文章，原標題是These Modern Programming Languages Will Make You Suffer，作者Ilya Suzdalnitski在文章中針對15種程式語言展開了詳細測評，希望對你有所幫助。
圖片來源：saashub
懶人目錄
概述篇：程式語言最重要的特徵
一星篇：C++，JAVA
二星篇：C#，Python，Rust，TypeScript
三星篇（上）：Go，JavaScript
三星篇（下）：Haskell，OCaml，Scala
四星篇：Elm，F#
五星篇：ReasonML，Elixir
ReasonML
ReasonML是一門最終會被編譯成JS語言的函數式語言，它主要應用在web前端開發中。ReasonML不是一門新語言，它是OCaml（一種古老而久經考驗的程式語言）的新語法。ReasonML由Facebook提供支持。
通過利用JavaScript生態系統，ReasonML沒有OCaml同樣的缺點。
所屬的編程語系：ML
不是JS的超集
ReasonML的語法和JS類似，這使得使用過JS的人很容易上手ReasonML。但是，不像TypeScript，ReasonML並不是JS的超集，也沒有繼承JS數十年來積累的一些糟糕設計。
學習時需要付出的代價
因為ReasonML不準備成為JS的超集，所以這門語言比JS簡單很多。任何有過用JS進行函數式編程經驗的人，都可以在差不多一周之內上手ReasonML。
ReasonML真的是這裡提到的最簡單的程式語言之一了。
函數式，但非純函數
不像Elm，ReasonML甚至不準備成為一門純的函數式語言，也沒有「永不出錯」的目標，這意味著ReasonML非常實用，並且專注於開發者生產力，能很快地實現結果。
類型系統
ReasonML就是OCaml，這意味著它的類型系統幾乎和Haskell一樣好，ReasonML類型系統最大的缺點是，缺乏類型類，不過它支持函子（更高階的模型）。
ReasonML是靜態類型的，它的類型推論幾乎和Haskell一樣好。
生態系統
不像TypeScript，ReasonML已經獲取了整個JS生態系統。
JS/TypeScript互操作
ReasonML編譯成純JS，因此可以在同一個項目中同時使用ReasonML和JS/TypeScript。
ReasonML與React——絕配
如果你正在進行web前端開發，那麼你就有機會使用React了。你是否了解，React最開始就是用OCaml寫的，然後才被移到JS上來幫助採用？
因為ReasonML是靜態類型的，所以無需擔心PropType。
還記得JS測評部分那個看上去無害但是卻導致了性能災難的例子嗎？
ReasonML對於不可變性數據結構有合適的支持，這樣的代碼不會造成性能問題：
id： 「0」，
firstName： 「John」，
}
friends=[samantha， liz， bobby]
onClick={id => Js.log（「clicked 」 ++ id）}
/>
與JavaScript不同的是，當使用ReasonML時，沒有任何東西會得到不必要的重新呈現，非常好的開箱即用的React性能。
工具
ReasonML幾乎不像它的替代語言們那樣成熟（比如TypeScript），它在工具方面有一些問題。舉個例子，官方推薦的VSCode擴展推論語言伺服器目前已損壞，不過還有其他替代品。
ReasonML在底層使用了OCaml編譯器，而OCaml以非常糟糕的編譯器錯誤消息而「臭名昭著」。雖然這不是致命的缺陷，但還是有點令人沮喪，並可能影響開發人員的生產力。
我希望隨著這門語言變成熟，它的相關工具能夠有所改進。
空值
ReasonML沒有空引用，它用Option模塊來表示可能不存在的值。
不可變性
ReasonML為不可變性數據結構提供了一流支持。
模式匹配
ReasonML有很好的模式匹配支持。
結論
ReasonML可能就是TypeScript想要實現的結果，只不過TypeScript失敗了。ReasonML在JS的基礎上增加了靜態類型，同時刪除了所有糟糕的特徵（並增加了真正重要的現代特徵）。
最佳前端語言獎
ReasonML獲得了「最佳前端語言獎」。毫無疑問，ReasonML是web前端開發最好的選擇。
Elixir
Elixir可能是世界上最受歡迎的函數式程式語言了。和ReasonML一樣，Elixir並不是一門真正的新語言。Elixir是在Erlang三十多年的成功之上建立的。
Elixir是Go的函數式表親。和Go相似，Elixir最開始就專注並發性來設計，這是為了利用多核處理器的優點。
和一些其他函數式語言不同的是，Elixir非常實用。Elixir專注於結果，我們不會在Elixir社區看到很多學術討論，Elixir論壇上充滿了實際問題的解決方案，這個社區對新手特別友好。
所屬的編程語系：ML
生態系統
Elixir的閃光點在於它的生態系統。在大多數其他程式語言中，語言和生態系統，是兩個獨立的東西。而在Elixir中，生態系統中的核心框架是由核心Elixir團隊開發的。
José Valim是Elixir語言的設計者，也是Phoenix和Ecot——Elixir生態系統中兩個超級酷的庫——的主要貢獻者。
在絕大多數其他語言中，有多個不同的庫專注同一個任務——許多不同的web伺服器，許多不同的ORM等等。在Elixir中，開發需要專注於一些核心的庫，因此庫的質量也非常高。
Elixir庫的文檔特別好，有許多例子。不像一些其他語言，Elixir的標準庫也有很多相關文檔。
Phoenix框架
Phoenix框架的口號是「Phoenix感覺剛剛好」。與其他語言中的框架不同，Phoenix有很多內置功能。它開箱即用，支持WebSocket、路由、HTML模板語言、國際化、JSON編碼器/解碼器、無縫ORM集成（Ecto）、會話、SPA工具箱等等。
Phoenix框架因強大的性能而出名，它能夠在一臺機器上處理數百萬個同步連接。
全棧Elixir
Phoenix框架最近引入了LiveView，它允許在Elixir中建立豐富的實時web接口（對比單頁應用程式）。不需要JS，也不需要React！
LiveView甚至可以負責同步客戶端和伺服器狀態，這意味著我們不必為REST/GraphQL API的開發和維護操心。
數據處理
當處理很多和數據處理相關的任務時，Elixir是Python的可靠替代品。在用Python和Elixir構建了一個網頁數據抓取工具之後，對比發現，Elixir對於這個任務，是一門更好的語言和生態系統。
像Broadway這樣的工具允許在Elixir中構建數據攝入/數據處理管道。
類型系統
在我看來，缺少恰當的靜態類型是Elixir最大的缺點。因為Elixir不是靜態類型，它的編譯器（以及dialyzer）會在編譯時報出很多錯誤。這和動態類型語言（比如JS， Python， 以及Clojure）有很大不同。
速度
Elixir編譯器是多線程的，提供了極快的編譯速度。與JVM不同，Erlang VM啟動速度很快。對於Elixir的用例來說，運行時性能非常好。
可靠性
Elixir是在Erlang之上創建的，Erlang花費了超過三十年的時間來創建世界上最可靠的軟體。一些在Erlang VM之上運行的程序能夠實現99.9999999%的可靠性。世界上沒有其他的平臺擁有同樣水平的可靠性。
並發性
大多數其他程式語言都不是為並發性而設計的。這意味著，編寫使用多線程/多處理器內核的代碼遠不是一件小事。
其他程式語言使用執行並行代碼的線程（以及線程讀/寫入的共享內存）。這種方法通常容易出錯，容易出現死鎖，並導致複雜性呈指數級增長。
Elixir構建在Erlang之上，Erlang以其出色的並發特性而聞名，它採用了一種完全不同的並發方法，稱為actor模型。
在這個模型中，進程（actor）之間沒有共享的內容。每個進程都保持各自的內部狀態，在不同進程之間通信的唯一方法是發送消息。
值得提及的是，正如它的創建者阿倫·凱（Alan Kay）最初所設想的那樣，actor模型實際上是OOP，它沒有任何東西是共享的，而對象只通過傳遞消息進行通信。
讓我們來快速對比Elixir和它命令式表親Go：
和Go不同，Elixir起初是為了容錯率而設計的。當一個goroutine崩潰時，整個Go程序都會崩潰。在Elixir中，當一個進程掛掉時，只有這一個進程會掛掉，而不會影響程序的其餘部分。
更好的是，失敗的進程會由主管自動進行重啟。這允許失敗的進程重試失敗的操作。
Elixir進程也非常輕量，一個人可以輕鬆地在一臺機器上執行成千上萬個進程。
擴展
讓我們再和Go作一個比較。Go和Elixir中的並發性都利用了並發進程之間的消息傳遞。因為Go編譯為本機代碼，所以Go程序在第一臺機器上運行得更快。
但是，一旦你開始擴展到第一臺機器之外，Go程序就會開始輸掉比賽。為什麼？因為Elixir從一開始的設計就是可以在多臺機器上運行的。
Elixir運行的Erlang VM在分發和擴展方面非常出色。它可以無縫處理許多繁瑣的事情，如集群、RPC功能和網絡。
在某種意義上，在微型服務真正面世的數十年前，Erlang VM就已經實現了微型服務。每個進程都可以被理解為一個微型服務——和微型服務一樣，每一個進程都是獨立的。
在語言內置通信機制的情況下，進程在多個機器上運行是一件普遍的事情。
沒有Kubernetes複雜度的微型服務？仔細了解一下，你就會理解Elixir設計的真正目的。
錯誤處理
Elixir用特殊的方法進行錯誤處理。純函數式語言（Haskell/Elm）被設計出來是讓錯誤的可能性最小化，而Elixir則假設錯誤一定會發生。
在Elixir中，允許拋出異常，但是捕獲異常一般是不被鼓勵的行為。進程主管會自動讓程序一直運行。
學習時需要付出的代價
Elixir是一門簡單的語言，新手可以花一到兩個月入門。使學習變得困難的是OTP。
OTP是Elixir的殺手級特性。OTP是一套來自Erlang的工具和庫，而Elixir是在Erlang基礎之上建立的。這是一種「秘方」，它大大簡化了並發和分布式程序的構建。
雖然Elixir本身很簡單，但使用OTP設計Elixir系統會花上一點時間，至少對我來說是如此。
學習資源
作為最受歡迎的程式語言，Elixir有著豐富的學習資源。這些學習資源往往對新手也很友好。
模式匹配
Elixir有很好的模式匹配支持。
數字處理
Elixir不能很好地處理計算密集型任務。編譯成本機語言的程式語言能夠更好地處理這些任務（比如Go/Rust）。
那Erlang怎麼樣？
對於企圖和目的，Elixir和Erlang的本質是相同的。Erlang是一種功能強大的語言，它的語法很奇怪。Elixir可以被認為是Erlang的一種更好、更現代的語法（還有非常好的生態系統和社區）。
結論
Elixir可能是所有函數式語言中最成熟的，它也可以在為函數式編程製作的虛擬機之上運行。Elixir最開始是針對並發性設計出來的，並且在多核處理器的現代社會中，它是最完美的搭配。
獎項
Elixir獲得了兩個獎項。
第一，它的彈性、函數優先的方法和驚人的生態系統使它成為「構建web API的最佳語言」。
第二，OTP和actor模型使得Elixir成為「構建並發和分布式程序的最佳語言」。和命令式表親Go不同的是，用Elixir編寫的軟體能夠橫向擴展到成千上萬個伺服器上，並且有開箱即用的容錯率。
寫在最後：在工作中使用正確的工具
圖片來源：Haupes Co。 / Unsplash
你會用螺絲刀錘釘子嗎？應該不會吧。那麼，我們也不應該試圖用一門程式語言完成所有任務，每一門語言都有它最合適的工作領域。
Go是最適合系統編程的語言。最適合前端開發的語言毫無疑問是ReasonML，它符合一門極好的程式語言的絕大部分要求。
Web API開發的冠軍絕對是Elixir，它唯一的缺點就是缺少靜態類型系統（這一缺點也因為其良好的生態系統、社區、可靠性，以及並發特徵而抵消了）。對於任何類型的並發軟體/分布式軟體，最好的選擇是Elixir。
如果你正在數據科學領域工作，那麼，非常遺憾的是，你只能選擇Python了。
文已至此，我衷心地希望，這篇文章能夠對你有所幫助。比較程式語言並不是一件容易的事，不過我已經盡力了。