作者 | Sergio De Simone
譯者 | 張健欣
策劃 | 丁曉昀
JetBrains在2011年7月釋出了Kotlin，旨在建立一種在 JVM 和 Web 上執行的現代通用程式語言。
Kotlin 是一種跨平臺的靜態型別語言，具有現代簡潔的語法，旨在克服Java開發停滯時期的 Java 缺陷。Kotlin 的關鍵特性包括 null 安全性、協程、資料型別、擴充套件函式等。
在 2011 年釋出後，Kotlin 花了一年時間實現了開源，又花了四年時間才在2016年1。0版本中實現了穩定。
僅僅三年之後，谷歌就將其作為 Android 開發的首選語言，這很快導致超過60%的專業Android開發者採用了它。最近，Jetpack Compose 1。0的釋出再次證實了谷歌對 Kotlin 的承諾。Jetpack Compose 1。0 完全使用該語言開發，並充分利用了其語法功能。
Kotlin 不僅僅是一種用於移動應用程式開發的語言，儘管它在這個領域取得了巨大的成功，在Play Store的前1000個應用程式中有80%以上使用Kotlin。事實上，據 JetBrains 稱，超過480萬名開發者已經將 Kotlin 用於伺服器端、移動多平臺、Android 和前端開發。
《Stack Overflow Developer Survey 2020》也證實了 Kotlin 的日益普及，該調查發現 JetBrains 的語言僅次於 Go 和 C/C++。
InfoQ 藉此機會，與 JetBrains 的 Kotlin 專案負責人 Roman Elizarov 進行了交談，以瞭解更多關於其過去、現在和未來的資訊。
InfoQ： Kotlin 很快就取得了巨大的成功，最引人注目的是在 Android 平臺上，它幾乎取代了 Java。你怎麼看待這些？
Roman Elizarov： 我們從最初發布的時間算起已經有 10 年了。如果你仔細考慮一下，就會發現它並沒有迅速取得巨大的成功。事實上，你會看到一種不同的模式，它極大地促進了 Kotlin 後來的成功。Kotlin 並不是閉門開發的。在 Kotlin 1。0 於 2016 年釋出之前，其一半以上的時間都是在根據早期採用者的真實反饋不斷進行測試和調整。2016 年曝光的穩定語言與 2011 年提出的最初想法大不相同。這是 Kotlin 成功的第一個組成部分——Kotlin 是務實的。它不是一種基於一小部分設計者的理論、哲學或假設的語言，而是一種基於實際使用資料的語言，旨在簡化從事大型專案的專業開發人員的日常工作。
使 Kotlin 脫穎而出的不是單一功能，而是它們的結合。從 null 安全和不變數的友好性，到對集合進行簡潔高效的功能操作，它們都是為了解決 Java 開發人員當時所遭受的具體痛苦而設計的。然而，儘管當前的目標是設計更好的 Java，但靈感來自各種語言，包括生產型語言和實驗型語言。
自 2016 年 Kotlin 穩定釋出以來，團隊非常重視向後相容性，這也是 Kotlin 真正增長和採用的開始。這是 Kotlin 之所以獲得成功的第二部分。作為一種行業語言，團隊對確保向後相容性的強烈關注隨著時間的推移獲得了回報。
事後看來，Kotlin 在 Android 的快速增長是合乎邏輯的，儘管它從未被計劃過。2017 年，當谷歌正式採用 Kotlin 時，它已經是一種成熟、穩定且經過戰鬥考驗的程式語言。
InfoQ： 展望現在和不久的將來，Kotlin 的進一步發展似乎與它作為伺服器端或全棧語言的採用有關。在這些環境中，Kotlin 達到了什麼成熟度級別？
Elizarov： Kotlin 在伺服器端的前景是光明的。這是 Kotlin 的主場——這個語言最初就是為伺服器端開發而設計的。伺服器端相當複雜，需要維護大量現有程式碼。這就是為什麼 Kotlin 設計優先考慮並將繼續優先考慮與現有 Java 程式碼和庫的良好互操作性。我們高興地看到我們的努力得到了回報。根據 Snyk 最近的 JVM 生態系統報告，18% 的 Java 開發人員已經使用了 Kotlin。我們預計這一數字將穩步增長。當然，由於領域的特殊性，伺服器端的增長不會像 Android 那樣快，但 Kotlin 會長期堅持，我們並不著急。
作為一種全棧、多平臺的語言，Kotlin 才剛剛起步。整個 Kotlin multiplatform 於 2017 年釋出，目前仍處於試驗階段。然而，我們看到我們的社群產生了巨大的興趣和參與度，這與我們在 Kotlin 1。0 之前得到的反饋非常相似。因此，我們再次採取了一種慎重的方法，在它們透過時間考驗並獲得現實反饋之前，我們不會急於穩定任何東西。基於過去的歷史，隨著我們從 Kotlin Multiplatform Mobile （KMM） 開始穩定 Kotlin multiplatform 的各個部分，我們預計對 Kotlin multiplatform 的採用會大大加快步伐。
InfoQ： Kotlin 沒有像 JVM 那樣在不同的虛擬機器實現上執行相同的位元組碼，而是透過編譯到不同的平臺來實現跨平臺支援。你認為，隨著 Kotlin 和其它語言採用相同的方法，Java 對“一次編寫，到處執行”的理解現在是否已經過時？
Elizarov： Java 的“一次編寫，到處執行”的思想在伺服器端取得了成功，但在前端——無論是 Web 端還是移動裝置端——都沒有成功。有太多特定於平臺的東西是 Java 太慢而無法適應的。即使在技術上可以執行 JVM 位元組碼的 Android 上，也不是每個 JVM 庫都能開箱即用。因此，你可以在任何地方執行任何東西的想法確實已經過時，但在平臺之間共享原始碼的願望仍然存在。這是一個不同的目標。
在我看來，Java 的主要錯誤是變得太大了，試圖將太多東西標準化並嵌入到平臺中，比如動態程式碼載入、XML 解析、甚至 UI 庫，這些東西經不起時間的考驗，結果只是曇花一現的時尚，而不是基本的東西。Java 模組化來的太晚了。在 Kotlin，我們正採取一種更為慎重的方法來擴充套件核心語言和核心庫。我們正在確保 Kotlin 在未來幾十年內保持相關性。此外，我們並不會幻想任何程式碼都可以在任何地方執行。我們的願景是，開發人員將明確地在腦海中保留他們希望程式碼執行的平臺列表，並且平臺之間總會存在一些需要偶爾考慮的差異。
InfoQ： 作為一種伺服器端語言或全棧語言，Kotlin 必須面對更激烈的競爭，（比它在 Android 平臺上贏得的競爭更激烈），包括最近引入的 Rust 和 Swift 等語言。你如何看待 Kotlin 在這個競技場上的表現？它的相對優點是什麼？
Elizarov： Rust 和 Swift 在各自的方面都是偉大的語言，但我不認為 Kotlin 在正面直接與它們競爭，只是在某些領域。
在我看來，Rust 更像是一種系統語言，更安全地替代了 C 和 C++。在 Rust 中，你可以精確地控制記憶體和其它資源，並且與 Kotlin 相比，具有更多的低級別程式碼效能調優能力。你可以用 Rust 編寫出色的應用程式軟體，但它將為開發人員帶來更陡峭的學習曲線、需要更多的努力和更詳細的程式碼，來告訴 Rust 編譯器你到底想做什麼。Kotlin 的做法完全相反。Kotlin 的目標是從程式碼中完全刪除任何儀式，包括記憶體管理，並讓應用程式開發人員專注於他們程式碼的實質——他們正在編寫的業務邏輯，即使這意味著犧牲一些執行時效能。
Swift 則不同。Swift 擁有現代的外觀和感覺，但它仍然延續了蘋果 Objective-C 的傳統，擁有許多蘋果生態系統之外的現代語言很少具有的功能和獨特的設計選擇。僅憑這一點，它就成為一種特殊市場定位的語言。此外，作為 Swift 的創造者，蘋果似乎對 Swift 在其它平臺上的未來並不感興趣，或者在外部觀察者看來是如此。對於 Kotlin 來說，這意味著在蘋果平臺上與 Swift 激烈競爭開發者們的意願，但幾乎不擔心 Kotlin 瞄準的所有其它平臺。
InfoQ： 你希望看到 Kotlin 在未來 10 年內如何發展？
Elizarov： 我們未來 10 年的主要重點是多平臺生態系統。我們仍然需要穩定它的核心部分，包括編譯器和工具，然後幫助社群提供生態系統繁榮所需的所有領域特定的庫。
就語言本身而言，這一切都是為了保持相關性，跟上所有現代趨勢和創新。我們目前正在經歷一場 UI 革命。響應式框架處於領先地位，Kotlin 正追趕潮流，全面採用 Jetpack Compose 作為 Kotlin 的現代 UI 正規化。隨著響應式程式設計在開發人員中流行，處理不可變資料的工效學成為該語言的首要關注點，這也是我們計劃在未來 10 年大力投入的領域之一。我個人確實可以預計，在這 10 年的晚些時候，伺服器端也會發生類似的變化，重點將從可變資料轉移到不可變資料，從命令式程式碼轉移到更具功能性的響應式程式碼。
處理資料是這裡的總體趨勢。隨著我們的資訊系統變得越來越複雜，我們經常發現自己不得不處理更不結構化的變化更大的資料結構。到目前為止，像 Python 和 JS 這樣的動態語言透過為開發人員提供一種任意資料的更簡單的方法而獲得了這種轉換的好處，但代價是生成在工業規模和複雜度上更難擴充套件和支援的程式碼。我們正在尋找將其中一些方法與 Kotlin 強大的靜態型別相結合的方法，以便為開發人員提供更好的工具來滿足他們所有的資料操作需求。我們對不斷增長的資料科學領域特別感興趣，並將在這一領域繼續改進。
隨著 Kotlin 擴充套件到伺服器端和移動裝置及其之外的更多領域，我們不能忽視支援更好的超程式設計功能的需求。許多領域都希望有自己獨特的特定領域的調整或擴充套件，這些調整或擴充套件根本不適用於常用庫的嚴格框架。Kotlin 最初被設計為非常適合領域特定語言（DSL），具有接收器、構建器和行內函數。但我們現在正在超越這一點。既擴充套件了 Kotlin 的行內函數的功能，又為編譯時計算提供了便利，還開發了編譯器外掛 API，用於對該語言進行更激進的領域特定擴充套件。
幾個月前，Kotlin 達到了 1。5 版本，引入了對一些最新 Java 特性的互操作支援，包括記錄類、密封介面、內聯類。此外，Kotlin 編譯器切換到一個新的 JVM 中間表示，目的是提高效能，併為新的語言特性提供基礎。Kotlin 可以作為 IntelliJ IDEA 和 Android Studio 的一部分安裝，也可以透過克隆它的 GitHub 倉庫安裝。
嘉賓簡介：
Roman Elizarov 是 JetBrains 的 Kotlin 專案負責人，目前以首席語言設計師的身份專注於 Kotlin 語言設計。在 2000 年，Roman Elizarov 從聖彼得堡 ITMO 畢業，開始了專業軟體開發生涯。在本科學習期間，他參加了國際大學生程式設計競賽（ICPC）。自 1997 年至今，Roman 擔任 ICPC 北歐地區首席法官。他還保持學術聯絡，並在 ITMO 教授併發和分散式程式設計課程。Roman Elizarov 的職業生涯的大部分時間都在 Devexperts 工作，他在那裡為領先的經紀公司和市場資料交付服務設計和開發了高效能的交易軟體，這些服務通常每秒處理數百萬個事件。他是 Java 和 JVM 方面的專家，特別是在併發、實時資料處理、演算法和現代架構的效能最佳化方面。自 2016 年以來，他一直在 JetBrains 從事 Kotlin 方面的工作，併為 Kotlin 協程的設計和 Kotlin 協程庫的開發做出了貢獻。
作者簡介：
Sergio De Simone 是一名軟體工程師。Sergio 在一系列不同的專案和公司擔任軟體工程師超過 15 年，包括西門子、惠普和小型初創企業等不同的工作環境。在過去的幾年中，他一直專注於移動平臺和相關技術的開發。他目前在 BigML，Inc。 工作，負責 iOS 和 OS X 開發。
https：//www。infoq。com/articles/kotlin-ten-years-qa/
