點擊上方關注，All in AI中國
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看看。
閱讀更多 AI中國 的文章
