為什么 Java 后端開發(fā)沒有大規(guī)模采用 Kotlin？
作者 | Ivan Sanchez 翻譯 | 王者
在使用了 Java 15 年后，我寫了第一行 Kotlin 代碼，到現(xiàn)在已經(jīng)差不多 5 年了。我們的團隊用Utterlyidle替代 Spring，用Totallylazy進行函數(shù)式編程。我們是 IntelliJ 的忠實粉絲，并試著充分利用它提供的 Java 工具。
那個時候，我們不只使用 Java。有一些團隊對 Scala 感興趣，并用它開發(fā)了一些服務。但是，因為 Scala 與 Java 代碼庫協(xié)作的復雜性以及緩慢的構建時間，對于我們大多數(shù)人來說，它并沒有太大吸引力。
2017 年，谷歌宣布 Kotlin 成為 Android 的官方開發(fā)語言，另一個與我們關系密切的團隊開始評估是否可以在他們的服務器端開發(fā)中使用它。最后，我們大多數(shù)人都去嘗試了一下。
我被 Kotlin 給代碼庫帶來的影響震撼到了。它給人的感覺是更高效、更安全，雖然開發(fā)工具沒有 Java 那么成熟，但也足夠好了。
從一門陳舊而冗長的編程語言中解脫出來，并探索哪些編碼風格更適合 Kotlin 的特性，這本身就是一件非常有趣的事情。Kotlin 與 Java 出色的互操作性意味著我們可以增量地依賴現(xiàn)有的生態(tài)系統(tǒng)和過渡系統(tǒng)，而不會對工作造成重大干擾。
很快，由于對 Kotlin 的興趣，我們一起開發(fā)了http4k，一個用于開發(fā) Kotlin HTTP 應用程序的工具包，并組織了Kotlin開發(fā)研討會，幫助其他團隊嘗試使用 Kotlin。
最后，我們看到其他各種項目也在服務器端使用 Kotlin，也看到了一些團隊強烈不愿意采用 Kotlin 的原因。
有意思的是，這種抗拒并不總是因為編程語言本身。那么，為什么 Java 服務器端開發(fā)社區(qū)沒有更多地采用 Kotlin 呢？
以下是我和我的同事們看到的一些原因。
“我們沒有時間學習一門新語言”
這也就是我們在軟件開發(fā)項目當中經(jīng)常看到的“忙著砍柴沒時間磨斧子”現(xiàn)象。這通常預示著更深層次問題，比如不斷增加的技術債務和開發(fā)效率問題。
健康的軟件項目需要開發(fā)者花大量時間去學習。一個有能力的 Java 開發(fā)者可以在數(shù)小時內掌握 Kotlin 的基本知識，并在數(shù)天內提高開發(fā)效率。
如果采用新語言可以讓他們寫的代碼更簡單，遇到的問題更少，那么投入就是值得的。
“Java 的每一個版本都在變得更好”
這是真的，Java 正在變得更好，而且發(fā)布的速度也越來越快。但是，對于處理空值這么簡單的事情，仍然遠遠落后于 Kotlin。
也許 Java 社區(qū)已經(jīng)習慣了這種演化速度。盡管如此，Kotlin 還是提供了一種方法，可以在項目中用上很多 Kotlin 特性。
“作為 Java 開發(fā)者，我們感到很自豪”
這種想法是最要命的。如果一個程序員把他們的專業(yè)身份和一種編程語言聯(lián)系在一起，那就沒有辦法了。
如果說 Java 開發(fā)者不想賭上自己的事業(yè)踏入一門新語言的未知領域，我可以理解。或者他們可能想成為一個領域的專家，這也很合理。
但是，我也并沒有看到哪個 Java 開發(fā)者因為使用 Kotlin 而“落后”了。相反，這表明他們一直在尋找適合自己的工具，這是一種積極的特質。
“Kotlin 是一種被炒作的語言，它的未來是未知的”
這是我們在 2017 年經(jīng)常聽到的反對采用 Kotlin 的說法。在那一年，谷歌宣布將 Kotlin 作為 Android 的官方開發(fā)語言，讓我們確信科技巨頭們對這門語言是感興趣的。
現(xiàn)在，Spring 和 Micronaut 等流行框架似乎已經(jīng)接受了這門新語言，之前的反對聲就不那么經(jīng)常聽到了。
希望這能讓更多的服務器端開發(fā)對這門語言有足夠的了解，并嘗試一下。
“我正在使用 Eclipse，不想切換到 IntelliJ”
在 Eclipse 中使用 Kotlin 的體驗與 JetBrains 的 IDEA 不太一樣。
這是可以理解的，因為銷售開發(fā)工具是 JetBrains 的商業(yè)模式之一，而且這種情況短期內不太可能改變。
對于這些人來說，他們能夠期望的是 Kotlin 可以達到一個質量臨界點，證明 Eclipse 為它提供進一步的支持是值得的。但在此之前，對于 Kotlin 開發(fā)者來說，最好的開發(fā)體驗仍然是使用 JetBrains 產(chǎn)品。
我認為，IntelliJ 已經(jīng)是一個更好的 Java IDE 了，所以它也值得一試。
“Kotlin 開發(fā)者太貴了，而且很難招到”
這一點很難說，從招聘網(wǎng)站的數(shù)據(jù)來看，Kotlin 開發(fā)者的薪資總體上略高一些。
如果我們只考慮服務器端開發(fā)者，就很難進行比較。一般來說，Java 開發(fā)者的薪資是最高的，但在 Kotlin 方面并沒有足夠的數(shù)據(jù)來進行比較。
有趣的是，在實際當中，我們可以看到高級 Java 開發(fā)者經(jīng)常是率先采用 Kotlin 的人，這可能會給人留下 Kotlin 開發(fā)者很“貴”的印象。
在招聘方面，我們并沒有覺得很難招到 Kotlin 開發(fā)者。我們很清楚，有些工作需要使用這門新語言，并允許開發(fā)者在工作中邊學邊用。
這似乎讓 Java 開發(fā)者放下心來，并吸引了那些熱衷于學習新事物的人。
“Kotlin 太復雜了”
Kotlin 之所以成為 Scala 等語言的替代語言，其中一個原因是它在易用性和高級特性之間取得了良好的平衡，與 Java 具有更好的互操作性，所以更有可能被流行框架采用。
在實際當中，這種反對聲與團隊的技能、風格和習慣有關。
初學者一般會像使用 Java 一樣使用 Kotlin，但隨著他們越來越熟悉這門語言，可能會深入使用一些特性(例如擴展和內聯(lián)函數(shù))，從而導致代碼庫變得越來越難以理解。
在團隊完全掌握新語言之前，我們建議盡可能長時間地使用普通的 Kotlin 特性。最后，團隊中的大多數(shù)人都會在選擇很酷的語言特性和保持代碼庫易于理解之間找到平衡點。
“在一個代碼庫中使用兩種語言讓人感到困惑”
這是在實際項目中沒有嘗試過 Kotlin 的人經(jīng)常會有的擔憂。
在實際當中，當團隊意識到新的 Kotlin 代碼需要與 Java 共存，那么在一個項目中使用兩種語言并不會給他們造成很大的痛苦。
這里有一個有用的規(guī)則：“如果一個變更涉及到兩種語言，首先將舊代碼轉換成 Kotlin”。
這樣，團隊就可以避免大爆炸式的重寫，并將需要添加新特性的地方進行逐步遷移。
如果需要保留一些 Java 代碼，那也沒關系。很有可能是因為這些代碼仍然有用，并且沒有進行重構的迫切需求。
“我們更喜歡 Java”
在實際當中，有一些場景不一定要使用 Kotlin，一切仍然能夠進行得很順利，團隊能夠以可接受的速度完成工作。
然而，根據(jù)我們的經(jīng)驗，這是例外，而不是常態(tài)。通常情況下，這種對語言的抗拒源于缺少時間和興趣，而不是因為沒有可提升的空間。
如果沒有在真正的項目中使用 Kotlin，是也很難體會到 Kotlin 的好處的。即使是作為一個實驗，也存在很多焦慮。
對于這種情況，我們建議“在工作中邊學邊用”(以編碼道場、培訓等形式)，創(chuàng)造一個可以進行這種實驗的安全環(huán)境。
這樣可以幫助團隊評估他們對 Java 的使用狀況，以及是否值得在 Kotlin 上投入。
“我看不出 Kotlin 會帶來什么好處”
有時候，Java 開發(fā)者意識不到語言方面存在的限制，或者是因為他們已經(jīng)習慣了。有時候，他們會抗拒新語言，因為新語言會讓他們質疑自己正在使用的語言。
在不深入細節(jié)的情況下，我們可以說 Kotlin 的簡潔性和安全性是它的主要優(yōu)點。然而，有些人聲稱他們不認為 Java 的冗長有什么問題，并且寫出來的代碼也很安全。
在真正去嘗試 Kotlin 之前，人們很容易將其忽略掉。而在真正面對它的時候，一些人會繼續(xù)尋找不嘗試使用它的理由。
一些想法
采用一種新的編程語言，特別是在正在進行的項目當中，這對于大多數(shù)團隊來說都是一個挑戰(zhàn)。對變化的抗拒與特定的環(huán)境有關，與項目需求和個人原因以及語言本身也有關。
話雖如此，我仍然鼓勵更多從事 Java 服務器端的開發(fā)者，如果有機會的話，可以嘗試一下 Kotlin。
往期推薦
關注我回復「加群」，加入Spring技術交流群