每個程式設計師都應該知道的下一個程式語言——Kotlin

Kotlin來自工業，而不是學術界。它解決了當今工作程式設計師面臨的問題。例如，型別系統可以幫助您避免空指標異常。研究語言往往根本就沒有空，但這對使用大型程式碼庫和API的人來說沒有用。

Kotlin是JetBrains的一種新程式語言，JetBrains是世界上最好的IDE的製造商。經過多次搜尋，我已經確定了它作為我將在未來5到10年左右使用的程式語言。

我非常喜歡Kotlin，並認為這將是一個非常成功的專案。在這篇文章中，我將解釋為什麼我認為Kotlin是好的。然後，我將討論如果您今天開始使用它可能遇到的一些問題。最後，我認為現在Kotlin已經出現了，如果你還沒有使用JVM（例如因為你使用Go或Node），你應該考慮使用JVM。

為什麼Kotlin很好？

這篇文章在大家一開始看的時候可能會很奇怪：通常語言倡導文章首先列出新語言的所有酷炫功能。但這篇文章沒有，我們稍後會講到。

我將首先向您介紹其他內容，因為2013年的一項研究表明，與開發人員評估程式語言時的生態系統問題相比，語言功能很少。這很符合我自己的經驗，所以，我們開始吧：

Kotlin編譯為JVM位元組碼或JavaScript。它不是您編寫核心的語言。對於今天使用Java的人來說，可能會非常感興趣，儘管它可以吸引所有使用垃圾收集執行時的程式設計師，包括目前使用Scala、Go、Python、Ruby和JavaScript的程式設計師。

Kotlin來自工業，而不是學術界。它解決了當今工作程式設計師面臨的問題。例如，型別系統可以幫助您避免空指標異常。研究語言往往根本就沒有null，但這對使用大型程式碼庫和API的人來說沒有用。

Kotlin不需要採用任何費用！它是開源的，但這不是我在這裡的意思。我的意思是有一個高質量、一鍵式Java到Kotlin轉換器工具，並強烈關注Java二進位制相容性。您可以一次將現有Java專案轉換為一個檔案，所有內容仍然可以編譯，即使對於執行數百萬行程式碼的複雜程式也是如此。這就是我採用Kotlin的方式，我希望它是大多數開發人員所做的。

作為上述的一個明顯的含義，Kotlin程式可以使用所有現有的Java框架和庫，甚至是依賴於註釋處理的高階框架。互操作是無縫的，不需要包裝器或介面卡層。它與Maven、Gradle和其他構建系統整合。

它是平易近人的，只需閱讀語言參考，就可以在幾個小時內學會它。語法簡潔直觀。Kotlin看起來很像Scala，但更簡單。語言很好地平衡了簡潔性和可讀性。

它沒有強制執行特定的程式設計哲學，例如過度功能或OOP樣式。

它不增加執行時開銷。標準庫小而緊湊：它主要包含Java標準庫的重點擴充套件。大量使用編譯時內聯意味著像map / filter / reduce管道的功能構造類似於相同程式碼的命令式版本。

結合Anko和Kovenant等框架的外觀，這種資源輕盈意味著Kotlin開始受到Android開發者的歡迎。如果你在Android上工作，你很快就會有好夥伴。您可以閱讀Square的開發人員撰寫的關於他們使用Kotlin和Android的經歷的報告。

Kotlin允許您繼續使用提高生產力的工具。如果使用IntelliJ、IDE互操作是完全無縫的：程式碼可以重構、搜尋、導航和自動完成，就像Kotlin程式碼是Java一樣，反之亦然。完全支援除錯、單元測試、分析等。

• 除了Android，我認為Kotlin非常適合企業Java商店。如果你整天都在大公司的大型Java程式碼庫上工作，你應該調查一下Kotlin，因為：

• 它得到了一家知名公司的強大商業支援。JetBrains致力於該專案，擁有一支龐大且非常稱職的團隊，擁有穩定的商業模式，甚至可以轉換部分自己的旗艦產品來使用它。Kotlin不太可能很快被拋棄。

• 採用Kotlin的風險很低：它可以在一小部分程式碼庫中由一兩個熱情的團隊成員進行試驗，而不會破壞專案的其餘部分：Kotlin類匯出一個看起來與常規Java程式碼相同的Java API。

• 採用Kotlin的風險很低：它可以在一小部分程式碼庫中由一兩個熱情的團隊成員進行試驗，而不會破壞專案的其餘部分：Kotlin類匯出一個看起來與常規Java程式碼相同的Java API。

• 因為Kotlin專注於可讀語法，所以程式碼審查不是問題：它們仍然可以由不熟悉該語言的團隊成員完成。

• 它以Java 6為目標，因此即使您的部署難以升級到較新的JVM，也可以使用它。

今年早些時候，我向一家大型保險公司Swiss Re的Java和.NET架構師團隊介紹了Kotlin。我首先定義了一個帶有幾個欄位的簡單Java類、toString、equals、hashCode等。它大約有50行程式碼。當我們完成將其轉換為Kotlin（主要是自動）時，它只縮小到一行程式碼。然後我演示了其他節省時間的功能。他們很熱情，並認為它是C＃的潛在強大競爭對手。

我認為Kotlin是企業Java開發人員的最佳選擇，所以即使Kotlin是免費的，我也希望JetBrains能夠通過增加IDE商業版本的銷量來扼殺它。這將激勵他們根據客戶的意願不斷改進。

與許多其他由不相關產品補貼的語言開發人員形成對比，這意味著當這些需求與預先存在的意識形態發生衝突時，他們幾乎沒有理由回應使用者的需求。

特徵

Kotlin因其專注於生態系統而在新的程式語言中脫穎而出：JetBrains明白生產力來自不僅僅來自於方便的語法。

儘管如此，Kotlin還是有許多有用的功能，可以讓編寫程式碼變得愉快：

• 我們已經提到了null安全性（可選性），它允許編譯器系統地標記潛在的空指標去引用。與某些語言不同，這不涉及選項型別，因此是零開銷。其他語言特徵保證了它的不方便。

• 精益語法：型別推斷無處不在，單行函式佔用一行，簡單的結構/ JavaBeans也可以在一行中宣告。真正的屬性在Java interop的幕後生成getFoo / setFoo方法。函式可以存在於類之外。

• 例外情況未經檢查。

• 將資料註釋新增到類會觸發樣板的自動生成，如equals、hashCode、toString、複製方法和變數傳播支援（重構）。這為您提供了方便的不可變類，而無需構建器。

• 但是，如果您確實需要構建複雜的結構，那麼語言功能的巧妙交叉會使構建器清晰且型別安全（讀取：自動完成）。如果您使用Google協議緩衝區來儲存結構化資料，那也會變得更容易。

• 功能程式設計支援零開銷lambdas，能夠在標準Java集合上進行對映、摺疊等。Kotlin型別系統區分集合的可變和不可變檢視。

• 擴充套件函式允許您在不修改原始碼的情況下向類新增方法。這首先看起來像一個表面的語法糖（syntax sugar），以避免FooUtils樣式類。然後你意識到以這種方式這樣做可以讓你通過自動完成輕鬆發現新方法，讓你構建強大的語言擴充套件，並允許你將現有的Java API與其他Kotlin功能整合。特點如......

• 運算子過載。但好的一面：這裡沒有Scala / Perl風格的線條噪音。運算子對映到特殊方法名稱，因此可以覆蓋現有運算子的行為（包括函式呼叫），但不能定義全新的運算子。這在功率和可讀性之間取得了平衡。

• Kotlin沒有重新定義語言的巨集或其他方法，但是一系列精心設計的功能允許像語言擴充套件一樣的庫比它們像物件集合一樣。一個很好的例子：你想使用光纖、演員和Go風格的頻道嗎？您可以使用名為Quasar的庫。

• Markdown而不是HTML文件的HTML。這使得編寫JavaDocs更加愉快。“Dokka”工具（相當於JavaDoc）可以讀取Kotlin和Java原始碼，並生成組合的doc網站，這些網站既有自己的風格，也有標準的JavaDoc HTML風格。

• 更好的範型。如果你從來沒有完全掌握super和extend在型別變數中的確切含義，不要擔心：這不是您的問題。Java的泛型確實令人困惑，Kotlin解決了這個問題。

• 委派（轉發方法）可以自動完成。

• ==運算子執行您實際期望的操作。

• 您想要快速方便的非同步程式設計嗎？當然，你會的。

• 字串插值“就像$ {this.example}！”

• 函式引數可以是命名的、可選的和可變引數。

• 許多其他調整和改進。如果有人對Java感到惱火，我會給它50/50，它已經在Kotlin中修復了。

現在就試試！

像許多現代語言一樣，Kotlin有辦法通過您的網路瀏覽器進行試用。與其他語言不同，Kotlin的試用網站實際上是一個完整的IDE，具有快速自動完成、實時背景編譯，甚至線上靜態分析！

現在就試試

繼續。我等你回來。

有什麼收穫？

注意：本文最初是在2015年7月編寫的。到目前為止，由於JetBrains修復了各種問題，因此本節已經不準確了。我已將下面已解決的問題標記為粗體，但保留原樣。

生活中沒有任何東西是完美的，Kotlin也不是。以下是我在使用該語言時遇到的一些問題。

資料類特性是自動生成JavaBean樣板的一種非常有用的方法，但它帶來了嚴重的限制：這些類不能從任何東西繼承，也不能繼承。反過來，這使得“密封類”功能變得不那麼有用，因為您不能擁有密封的資料類層次結構。JetBrains表示，當他們確切知道所涉及的行為應該是什麼時，他們希望放鬆未來版本中資料類的限制。 （Kotlin 1.1：資料類可能繼承自其他類）

還沒有型別別名。因此，必須每次都冗餘地寫出函式型別。 （1.1新增型別別名）

IDE外掛報異常的頻率仍然會比它多。這些似乎永遠不會破壞任何東西，因此與本機程式碼IDE中的崩潰相比，這是一個小麻煩。但“內部IDE錯誤”泡沫仍然可能是一種刺激。

預設情況下，類是最終的。如果您想要標準的Java行為，則必須將它們標記為“open”。一些依賴於位元組碼合成的Java框架假設類不是最終的，並且在遇到Kotlin程式碼時可能會失敗或默默地做錯事。這不是Kotlin的錯，但我仍然需要通過除錯來浪費大量的時間。隨著Kotlin越來越普及，我希望這些框架能夠得到改善。 （1.1為流行的框架新增了一些編譯器外掛，可以在適當的時候自動開啟類）

Kotlin支援編譯時函式內聯。這使得在執行時使用像map / filter / reduce這樣的高階函式非常便宜，因此使用它很常見。內聯還允許您在某些情況下解決JVM缺少reified泛型並執行非本地返回，例如從lambda內部退出函式。這些都是好事！但它們是有代價的：因為JVM不瞭解發生了什麼，堆疊跟蹤有時會搞砸。由於函式內聯，IntelliJ試圖“解擾”已經令人困惑的堆疊跟蹤，但是遇到引用不存在的行號和其他奇怪怪異的異常堆疊仍然很常見。理想情況下，Kotlin不必這樣做，因為JVM將具備所需的所有功能。但他們沒有，所以，除非JVM學習如何處理由語言前端內聯的函式，否則我們可能會堅持這一點。

Kotlin針對Java 6位元組碼，它沒有使用Java 8中的一些改進。一個小問題是Kotlin標準庫有時會複製Java 8標準庫提供的內容。此外，編譯器不使用“呼叫動態”位元組碼來減少lambdas生成的類檔案的數量，因此與Java 8相比，使用大量非可內聯lambda的Kotlin JAR可能會有點臃腫。修復此問題高高興起JetBrain的議程，希望很快就會完成。

IntelliJ內部的編譯是增量的，速度非常快（與Java一樣快）。通過Gradle編譯很慢，因為它根本不是增量的。如果可以，請避免通過Gradle進行編譯。同樣，這是他們要修復的事項列表中的高位。 （固定在1.1）

沒有相應的巨集或編譯器外掛，所以如果你喜歡來自Scala的巨集或像Java的Checker Framework這樣的東西，抱歉，你將不得不這樣做。

其他需要考慮的問題：

• 社群很小。雖然優秀的Java互操作意味著您並不真正需要Kotlin庫，但它們仍然很好用，目前並不多。

• FP純粹主義者可能會覺得型別系統缺少Scala或Haskell中可以找到的一些更高階的功能。如果你是那種比普通人更關心這個的，Kotlin可能不適合你。funKTionale庫將Haskell中已知的一些結構新增到語言中，如部分應用、函式區域性套用、記憶等。

• 雖然它可以編譯為JavaScript，但與Java後端相比，這種模式是實驗性的，並且很多次/未完成。 （在1.1中完成）

• 沒有標準的樣式指南，在某些方面，Kotlin為您提供了幾種可供選擇的語法。由不同的人寫的Kotlin可能看起來不同。這與Go形成對比，後者嚴格執行風格。 （現在有一個簡單的約定檔案）

• Kotlin有一個Eclipse外掛，但它自然不如IntelliJ支援複雜。如果您的團隊標準化IntelliJ，Kotlin將會發揮最佳作用。

• Kotlin比Java更挑剔。它不會自動將整數轉換為long，等等，您需要明確指定要轉換。這是因為該語言側重於正確性，並試圖解決著名的“Java Puzzlers”一書中的問題。JetBrains聲稱他們在網上找到了大約一半的內容。

• 因為Kotlin針對Java 6，所以它僅限於執行時具有的功能。雖然在許多領域它可以匹配或超過C＃，但它缺乏像Java平臺一樣不屬於價值型別的功能。

為什麼要考慮JVM

最近我遇到過許多使用動態指令碼語言（如JavaScript或Go）的初創公司。

當我在比特幣空間工作時，使用動態語言尤其令人痛苦;這類工具缺乏型別安全性，已導致嚴重的貨幣損失。Go不易出錯，但仍然因缺乏基本功能而受到嚴重影響，例如良好的偵錯程式、快速GC、可靠的依賴關係管理和可靠的分析工具。

在過去15年左右的時間裡，Java與冗長和過度工程密切相關。在很大程度上，這種聲譽是應得的。Enterprise Java因類名為PathVariableMapMethodArgumentResolver的類而聞名。

最終，我被迫通過Android返回Java。原來事情發生了變化。雖然XML仍然比時尚所要求的更頻繁地出現，但基礎設施的能力已經變得非常令人印象深刻。IntelliJ比Eclipse更快、更直觀。Maven雖然起初相當具有壓倒性，但在另一個構建/依賴管理系統中，我常常希望擁有大量功能。Ninja和Play等較新的Web框架從Ruby on Rails等專案中學到了輕鬆。有大量的庫，硬體變得更好，JVM效率也更高了。

沒有真正改變的一件大事就是語言本身。編寫Java仍然冗長且痛苦。

現在有了Kotlin，隨之而來的是與Java生態系統相關的最後一次傳統痛苦已經消失。您可以編寫比指令碼語言更具表現力和更簡潔的程式碼，但可以減少錯誤並提高效能。您可以使用所有優秀的工具：只需嘗試捆綁的VisualVM程式，即可體驗這個生態系統中免費提供的內容，或者檢視Chronon time - traveling偵錯程式，看看如果您願意支付一些錢，您可以獲得什麼。

如果你的JavaScript是你的東西，試試Kotlin的JS後端。或者，在Nashorn JS引擎中執行現有程式碼。

如果你喜歡JavaScript，試試Kotlin的JS後端。它為每個平臺建立本地捆綁包，這意味著在Linux上，您可以獲得完全獨立且沒有JRE依賴性的DEB或tarball。當然，一旦解壓縮，它不是單個檔案，但從部署角度來看，單個目錄並不難。

簡而言之：如果你以前忽略了JVM生態系統，是因為它終端不酷，你應該仔細研究下kotlin看看。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31545819/viewspace-2219352/，如需轉載，請註明出處，否則將追究法律責任。