早在 2002 年，Rod Johnson 就提出了對 Java 企業級開發的批判性看法，並推出了一種更加簡潔、靈活的替代方案——Spring 框架。20 多年後，這位從事程式設計 30 多年的元老級碼農又燃起了對 Kotlin 的興趣。那麼，是什麼讓他棄 Java 轉向 Spring？他又是如何看待 Kotlin 的未來的呢？
最近，Rod Johnson 在播客節目中，與主持人 Sebastian 和 Márton 詳細回憶了 Spring 誕生故事，並分享了他最近重返 JVM 的歷程，以及作為 Kotlin 新手的種種樂趣。基於該播客影片，InfoQ 進行了部分增刪。
核心觀點如下：
-
開源需要激發人們的興奮感，這不僅僅是財務激勵的問題，更是關於構建組織、建立企業併產生影響力的問題。
-
Kotlin 更友好、更易讀、寫起來更有趣，它是一個更現代的語言。
-
Kotlin 具備了 Python 讓我喜歡的所有優點，卻沒有那些我不喜歡的缺點。
-
Kotlin 語言本身似乎也沒有給人一種“透過做最複雜的事情來彰顯聰明才智”的感覺，這種專注於清晰和可讀性的氛圍是非常健康的。
Márton：Spring 是如何誕生的？
Rod： 我認為，許多成功的軟體往往都源自於開發者曾經親身經歷過痛苦。因此，Spring 之所以能夠成功，其中一個原因是，最初參與 Spring 開發的許多開發者，很多是從企業應用開發領域走出來的。
Spring 的誕生可以說有些特殊。許多核心理念，比如後來被稱為“依賴注入”，我是在 1999 到 2000 年期間在倫敦工作時提出的。隨後，我寫了一本書，進一步闡述了這些理念，並認為用程式碼來展示這些思想將是一個有用的示例。之後，讀了這本書的人找到了我，詢問這些程式碼的許可問題，能否在實際應用中使用，同時也問是否能幫忙改進這些程式碼。因此，Spring 的開源專案實際上就是從這本書開始的。
Sebastian：從一個框架的設想，到將它轉化為一個實際的、能夠持續維護的框架，並且準備好供他人使用，這個過程還是相當具有挑戰性的。
Rod： 我認為從一本書開始的確比我當時意識到的更具優勢，因為這意味著每個人都在同一頁面上，沒有關於架構風格的爭議。實際上，今天 Spring 一個非常顯著的特點就是它的一致性。如果你瞭解 Spring 的某一部分，你就知道其他部分是如何運作的。
團隊成員的質量也起到了重要作用。比如，Juergen Hoeller 就是一位令人驚歎的開發者，第一位貢獻大量程式碼的人竟然是這樣一位如今享有盛譽的開發者，這無疑也有一定的運氣成分。社群也起到了非常重要的作用，那時開源社群還沒有什麼行為規範，但我們自己就是正直的人，不容忍任何不良行為，真心想幫助他人，尊重他人，盡力回答問題。我認為，這也使得團隊隨著發展，始終保持著專業和良好的行為，社群成員也十分感激這一點。
將 Spring 發展成為一個主流框架，要求我們做出艱苦的努力和一些好運。我認為自己對商業的興趣也在其中扮演了非常重要的角色。早在 2004 年，我就清楚地表達了，Spring 必須有一個可行的商業模式，因為這個專案太雄心勃勃、太複雜，單靠志願開發者是無法支撐下去的。
2000 年代初到中期，Java 開源市場上有兩個重要的玩家：JBoss 和 Spring。我認為 Boss 並不具創新性，如果你有能力使用 WebLogic，你會選擇 WebLogic，而不是 JBoss，因為 WebLogic 本身就更好。JBoss 的重要性在於它讓你不需要購買昂貴的應用伺服器，但它本質上是開源市場的商品化。Spring 則不同，它提供了從 BAA、Oracle、Sun 或 IBM 那裡無法獲得的東西，而要做到這一點，必須有一個穩固的經濟模型。
Sebastian：首先，關於 Spring 框架的一致性，雖然它有很多動態的部分，但如果支撐它的思維模型是一致的，你就可以在不同的部分之間做出合理的假設，這點總是讓人感到非常愉快，這也是我喜歡 Kotlin 的一部分原因。我一直形容它就像是有很多不同的零件，它們像樂高積木一樣拼接在一起，你能很清楚地看到這些部分如何組合在一起，背後有一種相對一致的哲學。您能否進一步擴充套件一下關於在開源背景下，如何實現可持續發展呢？
Rod：Spring 不僅規模巨大，而且與眾多其他工具有整合，因此我們很早就遇到了這樣一個問題：IBM 在每個 WebSphere 的重大版本釋出時，總喜歡玩一個遊戲，叫作“把事務管理器放到一個你找不到的地方”。此外，還存在一些不同產品中的 bug 和效能問題，這些問題需要迅速解決，但無法依賴於志願者開源社群來解決。在 2000 年代每一個 WebSphere 版本釋出時，Juergen 都確保 Spring 與該版本完美相容。但即使 Jurgen 再優秀，也無法保證他會把這個問題列為待辦事項的首位，尤其是他不全職從事 Spring 工作的話。
說實話，我對開源的現狀有些沮喪。曾經有一段時間，開源正在確立自己作為一個商業類別，我認為 JBoss 在這一過程中發揮了非常重要的作用，因為它展示了你可以擁有一種不同的模式，使公司和個人能夠更容易地獲得技術。大概直到 2010 年代初期，似乎開源收購變得越來越大，且這種現象從商業角度看具有很強的潛力。然而，不幸的是，向雲計算的轉移在這方面造成了不少問題。
我認為，開源如果能夠維持可持續發展，對幾乎所有人都有好處。我相信開源開發者如果不能從中創造財富，是不利的。例如，如果我唯一能期望的就是找到一份薪水不錯的工作，我可能就沒有太多動力了。開源需要激發人們的興奮感，這不僅僅是財務激勵的問題，更是關於構建組織、建立企業併產生影響力的問題。比如，Elasticsearch 的 Shay Banon，他並不是為了成為一名員工而工作，即使他得到了很好的認可和薪酬，他的動力來自於創造某種東西，做出改變，並且在這一過程中擁有更多的話語權。
Márton：開源專案通常需要非常有激情的個人付出巨大的努力來推動，最終才能實現可持續發展，同時必須擁有某種盈利模式。而 Spring 的故事也很有意思，它來自一群實際開發應用的人員，而不是那些單純為了框架而創造框架的人，這與 Kotlin 的誕生非常相似。Kotlin 也不是一個學術性專案，而是在 JetBrains 的開發者希望用它來支援他們的實際產品時誕生的。那麼，你是如何開始使用 Kotlin 的呢？
Rod： 我實際上有很長一段時間遠離了 Java 和 Spring。大概在 2009 年 SpringSource 被收購的時候，接下來的兩三年裡，我幾乎沒有寫什麼程式碼。後來，我真正開始接觸 Scala，之後由於參與的多個專案，我做了很多 TypeScript 和 Python 的工作。大約在去年此時，我對 Python 感到厭倦，決定將開發語言換成 Java 和 Spring。那時我當然知道 Kotlin 已經推出，而由於我已經熟悉 Scala，學習 Kotlin 似乎是順理成章的選擇。
但是，我還是有意識地花時間將自己更新到現代 Java 的水平，因為我最後一次寫 Java 程式碼，可能還是 Java 7。我認為，在深入瞭解其他技術之前，我應該先徹底熟悉 Java。事實上，Java 的確有很多改進。然而，最終我還是對 Java 中的流操作感到厭煩，坦白說真是有些尷尬。我記得我是在散步時決定，“好吧，試試 Kotlin 吧，總比這強。”我覺得 Kotlin 的學習曲線非常平緩，大約兩個月之後，我幾乎完全不想再寫 Java 程式碼了。所以，現在我寫的所有程式碼都是 Kotlin。儘管如此，我從來不會成為 Java 的“黑粉”，事實上，我認為現代 Java 實際上比人們給的評價要好得多。
然而，如果有機會使用 Kotlin，我真的覺得很難拒絕它，因為 Kotlin 更友好、更易讀、寫起來更有趣，它是一個更現代的語言。當然，我在個人專案中也對 Scala 有過同樣的感受，但即使在我最熱衷 Scala 的時期，我也能清楚地看到，作為經理，如果我要管理大規模專案，我可能不希望團隊使用 Scala，因為我們都知道，使用 Scala 的大型專案常常會帶來問題。但 Kotlin 就不會有這種感覺，Kotlin 中的所有特性，我認為都很實用，它來源於實踐者，而非學術界。每個特性似乎都是為了某個實際目的而存在，而不是為了迎合學術上的時尚。
另外，你可以在 Kotlin 裡看到 Scala 的很多經驗和元素。這是一個非常寶貴的經驗，因為它讓我們看到什麼是可能的，然後我們想，或許我們可以用更實用的方式實現這些功能。
Márton：有一場非常精彩的演講，標題大概是《站在巨人的肩膀上（Shoulders of giants）》，演講者講述了 Kotlin 如何建立在 Scala 這樣的技術基礎上，以及從中學到的經驗。他還提到，Kotlin 在構建過程中吸取了包括 Python 在內的其他語言的特性，作為其某些功能的基礎。
Rod： 使用 Kotlin 有兩件事讓我感到驚訝。第一件事是我竟然這麼喜歡它。第二件事是，我的 Kotlin 程式碼看起來竟然很像 Python。雖然我寫了很多 Python 程式碼，但總體上我並不喜歡 Python 作為語言。然而，Kotlin 具備了 Python 讓我喜歡的所有優點，卻沒有那些我不喜歡的缺點。例如，它具備了 Python 的清晰性和可讀性，但它有更好的型別系統，並且讓我能夠使用 Spring，能夠在 JVM 上執行。
Márton：我認為回顧 Kotlin 最初的定位和專注於 JVM 的背景，真的很有意義。而且，回想一下每個人第一次接觸 Kotlin 的時刻，我覺得我們所有人都有類似的體驗。我寫的 Kotlin 程式碼越多，我就越為之欣喜。我相信，很多聽眾也經歷了類似的體驗，尤其是在他們第一次開始使用 Kotlin 時。
Rod：Kotlin 的學習真的幾乎沒有痛點，沒有太多讓你一開始就容易犯錯的地方。其次，如果你已經熟悉 JVM，當然可能是從 Java 入手，但如果你至少了解 Python 或 Scala，我認為學習 Kotlin 會非常容易。更不用說，現在我們有了一個絕佳的學習資源——LLMs。基本上，ChatGPT 幫助我以比其他方式快得多的速度學習 Python，它也在學習 Kotlin 時幫助了我不少。
我發現 LLMs 在寫 Kotlin 程式碼時表現得非常出色。儘管我同時使用 Python、Java 和 Kotlin，但 Kotlin 的程式碼完成質量遠高於 Python 和 Java。雖然這聽起來有點意外，因為 Python 和 Java 是最廣泛使用的兩種語言，但考慮到它們的最佳實踐已經發生了很多變化，這一現象是可以理解的。
現在，寫 Python 應該使用型別提示等更新特性，尤其是 Python 3.10 及以上版本，而 Java 也應使用 records 等新特性。相比之下，Kotlin 並沒有這些問題，吸引了許多早期採用者，許多高質量的程式碼由這些開發者編寫。
最初我對 Kotlin 的程式碼質量感到意外，但隨著時間推移，我發現 Python 和 Java 的程式碼質量差異更加明顯。對於 Kotlin，我幾乎從未收到糟糕的程式碼建議，而 Python 和 Java 中，儘管我調整提示語，仍常得到我現在絕不會寫的程式碼。
Sebatian： 我們也認為，Kotlin 語言內部的高度一致性可能有助於 LLMs 的表現。在 JetBrains，我們特別在 AI 助手方面做了一些工作，IDE 中的模型已經針對 Kotlin 程式碼進行了微調。我認為 Kotlin 在這些年裡保持了一致的發展路線。如果回顧三到五年前的 Kotlin 程式碼，儘管有些差異，但許多核心原則依然適用。我很好奇，雖然我自己沒有嘗試過，但想了解一下你用的 LLMs，是否已經開始建議你使用 Kotlin 中一些“現代”的特性，比如函式式介面、上下文接收器，我很好奇 LLMs 是否已經能夠充分利用 Kotlin 的所有語言特性。
Rod： 總體來說，LLMs 提供的建議質量似乎相當不錯。我不太記得它是否建議使用函式式介面，但總體上，它的建議看起來符合 Kotlin 的習慣用法。
Sebastian：這是我個人覺得非常有趣的一點，尤其是提到 Kotlin 中的作用域函式（scope functions）。像 let、apply、run 這些函式，確實需要一點時間來適應。當我看到一段看起來比較像 Java 的程式碼時，裡面可能只是做了幾個空值檢查，或者已經使用了 Kotlin 的智慧型別轉換特性，但它們仍然只是簡單地堆疊空值檢查。這時，我向 LLM 詢問，“有沒有更好的方法來寫這些？”結果它把這段程式碼轉換成了使用 Elvis 運算子和早期返回的寫法，實際上充分利用了 Kotlin 語言能夠根據返回路徑推斷空值性的特性。這個轉換讓我感到非常震驚，我必須承認，這種體驗真的讓我大開眼界。
Rod： 我完全同意，我認為大部分的建議確實是符合 Kotlin 的習慣用法。如果我在討論程式碼時使用 LLM，我通常會選擇 Claude，因為我認為 Claude 在處理程式碼時的表現要好很多，尤其是在持續的程式碼推理方面。
我認為 Kotlin 的一個真正優點就是，你可以在沒有太大痛苦的情況下開始使用它。有些語言你根本不能輕鬆上手，比如 C 或 C++。事實上，我認為 Java 之所以如此成功，其中一個原因就是它是一門你可以毫不費力地開始使用的語言。編寫的程式碼不太可能引發那些不明顯、嚴重的問題。因此，我絕對認為，對於轉向 Kotlin 的開發者，他們應該放輕鬆。如果一開始他們寫的程式碼沒有使用很多 Java 做不到的特性，那也沒關係。畢竟，這不是他們一年後寫的程式碼，他們可能會回來進行修改，但那也不會導致什麼嚴重問題。所以，我認為 Kotlin 的學習過程是沒有壓力的。
關於程式碼的可讀性，這其實是很主觀的，但我總體來說覺得，Kotlin 程式碼並不難讀。而與此相對，Scala 中有許多人有自己的寫法和習慣，而且不幸的是，Scala 社群曾經被那些功能程式設計的狂熱者主導，他們堅信一切必須是純粹的。相反，我覺得 Kotlin 不僅是一個可讀性很高的語言，而且它似乎也不容易吸引那種過於追求“純粹性”的人群。
Sebatian：在 Kotlin 的世界裡，人們通常都非常務實。你剛剛說自己還沒有完全接受 Kotlin 中的擴充套件函式。這個話題值得深入討論，因為我們在與許多人交流，或者在社交媒體上看到，很多人都把擴充套件函式作為他們愛上 Kotlin 的第一大特性。所以，我很想知道你對擴充套件函式的看法是什麼？能和我們分享一下你不喜歡它的原因嗎？
Rod： 我理解為什麼擴充套件函式在框架中非常有價值。Kotlin 的一個優勢是，它不像 Scala 社群那樣在 JVM 上重新發明每一個輪子，而是擁抱了現有的技術。我完全理解，能夠輕鬆編寫物件對映、註冊 Kotlin 模組等功能，確實使得許多現有的 Java 工具變得更好用。
不過，我自己在程式碼中並沒有廣泛使用擴充套件函式。雖然在使用像 Jackson 這樣的庫時，我實際上受益於擴充套件函式，但我對它是否真的必要仍持懷疑態度。對我來說，擴充套件函式有點像“魔法”，而且坦白說，我從 C++ 轉到 Java 的一個原因就是，C++ 中你必須到處尋找類定義，而 Java 則更具指導性，類定義明確、可預測。所以，儘管 Kotlin 中的擴充套件函式需要匯入，我其實更喜歡這一點，它限制了擴充套件函式的作用範圍。
老實說，我並沒有過多使用擴充套件函式。實際上，有幾次是 LLM 建議我使用擴充套件函式，我可能保留了一兩個，但通常我對它持懷疑態度。我認為它是一個很好的整合功能，幫助更好地利用 Java 庫，但對我個人而言，我並不覺得自己有強烈的需求去使用它。
Sebatian：我覺得 Kotlin 的一個魅力就在於，你可以根據自己的需要選擇使用不同的語言特性。從 Kotlin 誕生以來，這種靈活性一直存在。我想說的是，Kotlin 經歷了典型的“炒作週期”。當一個新的語言特性推出，或者團隊開始採用 Kotlin 並學習到新的特性時，往往會出現一種“全力以赴”的現象——他們可能會過度使用這些新特性，突然之間，所有的東西都變成了擴充套件函式，或者所有的東西都變成了頂級函式。然後，隨著時間的推移，人們會逐漸明白這些特性帶來的維護負擔，或者它們對程式碼可讀性產生的影響，最終大家會找到一個適合自己的平衡點。
Márton：當團隊第一次採用 Kotlin 時，確實會出現這樣的情況：他們一開始寫得像 Java 一樣，過度使用特性，然後不得不進行調整，避免使用過多層次的巢狀作用域函式，以及各種他們試圖塞進程式碼中的“魔法”特性。
Rod： 其實，我得承認，我並沒有仔細檢視過 Kotlin 的語言發展路線圖，也沒太關注它是如何發展到今天的。我只是使用當前版本，老實說，我喜歡這種不需要去關注路線圖的感覺。目前，我可能在 Kotlin 和 TypeScript 之間非常糾結，都是我最喜歡的語言。如果讓我選擇，我可能會選擇 Java 加 Spring，而不是 TypeScript 加 Node.js。所以，如果有兩種語言在質量上不相上下，我的選擇還是偏向於 Kotlin。
不過，確實有些特性我還挺懷念的，比如我很懷念聯合型別和型別代數。雖然我知道有時候這些特性可能會用得過度，但像聯合型別和部分型別這樣的特性真的非常有用。唯一一個我覺得有點問題的地方是 Kotlin 中的物件字面量語法，其他的 Kotlin 語法我都覺得很漂亮、簡潔。
Márton：Kotlin 也在逐步演進，一些最初沒有的語言特性現在已經變得習以為常。這種進化非常有趣，既有堅實的基礎，又在不斷前進。每次更新都一步一步地推出新特性，這些小變化累積起來推動了 Kotlin 的進化。現在我們已經超越了 2.0，迎來了新的編譯器，未來語言的演進速度可能會加快，因為新編譯器的推出將使我們能夠在不需要實現的情況下推進更多新特性。
Rod： 從語言版本的角度來看，Kotlin 顯然比 Scala 要輕鬆得多。Scala 的一個顯著問題就是版本不斷變化，導致很多東西被打破，這一直是使用 Scala 的一個大問題，直到現在依然如此。
另外，我一直認為，大家對程式語言的關注過於集中，而生態系統實際上是至關重要的。如果你看看 Kotlin，它與 Java 世界的整合非常出色，這與當時你在使用 Scala 時的體驗截然不同。Scala 當然也能將 Java 程式碼寫得更優雅，但是你也能遇到另一種情況，有人用 Scala 寫的程式碼可能只有他們自己能理解，而他們還為此感到驕傲。但如果你在一個需要和 Java 庫進行互動的環境中工作，Scala 的互操作性就非常痛苦。你會發現，你花了大量時間在解決這些互操作性的問題上。
相比之下，Kotlin 的互操作性幾乎為零，這真的非常了不起。我必須承認，雖然我多年來偶爾有接觸 Kotlin，知道它與 Java 的整合非常好，但我還是花了大約兩三週的時間在 Kotlin 中心想，“好像應該快出現什麼問題了，這一切太順利了，遲早會碰到什麼麻煩的整合問題。”但事實是，我並沒有遇到任何麻煩。
我其實並沒有深入研究 Kotlin 底層是如何實現的，但我可以想象，它從 Scala 的經驗中受益匪淺。比如，Kotlin 如何提供非常好的集合庫，而不會給開發者帶來痛苦。這是一個很大的優勢，因為 Scala 在這方面曾經經歷過一些問題，而 Kotlin 顯然透過這些經驗做得更加順暢。
Sebastian：我覺得你提到的批評是非常有道理的，尤其是你說在與 TypeScript 合作時，有一些東西在型別系統上缺失。我個人也同意這個看法。實際上，我們的語言設計團隊也在關注這些問題。我們希望確保 Kotlin 能夠與語言中的所有運算子等進行良好的整合。所以，我希望我們能夠找到比 Java 中當前的受檢異常更符合人體工程學的解決方案，這也是我最大的期望。
Rod： 比較密封層次結構和聯合型別時，我的經驗是，密封層次結構是一個相對邊際的特性，雖然它有一些價值，但聯合型別的價值要大得多。使用密封層次結構時，你必須在開始時就知道太多資訊，而聯合型別則允許你在消費資料時定義自己的規則，這實際上是它的一大優勢。使用密封層次結構時，所有的規則必須事先定義好，而聯合型別則更靈活，允許你根據需要動態地定義處理方式。
Sebastian：你覺得 Kotlin 作為語言和 Spring 作為框架的結合如何？你覺得它們之間的契合度怎麼樣？
Rod：Kotlin 和 Spring 的結合現在幾乎是完美的。多年來，Spring 一直傾向於使用建構函式注入，這與 Kotlin 的寫法非常契合。我現在幾乎不再使用 is，而是大量使用不可變物件。Kotlin 編譯器的 Spring 外掛非常重要，因為有時類預設需要是 open 的。剛開始時我不喜歡這種方式，更傾向於顯式地寫 open，但後來我意識到這種做法其實是個好主意。
現在的 Spring 非常簡潔，沒有冗餘的部分。XML 已經消失了 10 到 15 年，通常只需要定義一次。而即便是在使用現代 Java 時，尤其是建構函式等情況，常常需要多次宣告。因此，我認為，如果 Spring 開發者想真正體驗 Spring 的強大，應該嘗試使用 Kotlin 而非 Java。你會發現，很多表面上的稜角其實並不是 Spring 的問題，而是 Java 本身的問題。Java 21 及以上版本的 Spring 已經相當不錯，儘管它常常受到不公平的批評。如果有選擇使用 Kotlin，我認為 Kotlin 更合適，它更現代，程式碼沒有重複，很多東西只需寫一次。
對於我使用的庫，Kotlin 的擴充套件函式在 Jackson 中的應用非常好，使得操作更加順暢。一旦註冊了 Kotlin 模組，Jackson 就能順利工作。不過，唯一讓我覺得不太優雅的是 JPA。其實，我從不認為物件關係對映是壞事，反而認為它是一種強大的技術。如果你懂得如何使用，JPA 和 Hibernate 的實現已經比其他替代方案好很多。雖然 Kotlin 在使用 JPA 和 Hibernate 時的表現比 Java 好，但我覺得它與 Kotlin 的自然風格不完全契合，主要是因為 JPA 基於可變性設計，而 Kotlin 則更傾向於不可變性。這並不是 Kotlin 的問題，而是處理一個本身就需要可變性的 API。
總的來說，儘管 JPA 與 Kotlin 的結合沒有我在其他領域的使用體驗那麼愉快，但它依然能正常工作，並且與 Spring 資料倉庫的整合非常好。我現在不再使用 Optional，而是直接使用可空型別，並且它工作得非常好。
Sebastian：作為有一定 Spring 經驗的開發者，你的學習路徑可能會不同於普通開發者。你的學習過程是從寫類似 Java 的程式碼開始，然後逐步轉向 Kotlin，還是依賴於一些示例來加深理解的呢？
Rod： 我有一個使用現代 Java 構建的 Spring 應用程式，並且採用了當前所有的最佳實踐。Spring 文件對於 Kotlin 的支援非常好，其中包含了許多示例，明確說明你可以選擇使用 Kotlin 或 Java。因此，Kotlin 始終是一個完全受支援的選擇。除了我提到的預設 open 問題之外，Kotlin 的學習曲線幾乎不存在，這個問題同樣適用於一些其他框架，如 JPA 等。
此外，由於我已經熟悉 Spring，學習 Kotlin 時並沒有遇到任何驚訝。對於這些技術的整合，我沒有任何問題。正如我之前提到的，在現代 Spring 中，你已經開始使用不可變性等功能。例如，在使用 Spring 的配置屬性源時，資料類會被自動注入。如果你想在 Kotlin 中使用某個語言特性，它通常能與 Spring 的相關功能很好地相容。
Márton：你曾在 2013 年 Scala Days 上發表過一場廣為引用的演講，討論了 Scala 在 2018 年的發展願景，講述了 Scala 需要在五年內達到的目標，以便能夠廣泛採用並實現穩定。現在，Kotlin 也正接近這種狀態，距離它最初的穩定釋出已經接近 10 年。你是否已經有了一些關於 Kotlin 未來五年的想法？你期望這個語言在那時會有哪些發展或變化？
Rod： 我必須承認我並沒有仔細思考過這個問題。2013 年關於 Scala 的願景，大部分是關於解決我認為阻礙 Scala adoption 的痛點，比如二進位制不相容性等問題。這些痛點直接影響了人們能夠從 Scala 中受益的程度。因此，當時的願景是圍繞著需要解決這些問題，以減少痛苦。
對於 Kotlin 來說，情況會很不一樣。我認為，首先 Kotlin 應該繼續擁抱 Java 生態系統，尤其是在 JVM 上執行時。JVM 非常重要，Kotlin 在這方面的優勢是巨大的。你可以使用 Spring、Jackson、JPA 等技術，而且它們都能很好地相容並且執行得很順利。此外，我認為，雖然可能在相容性上有一些挑戰，但基本的型別代數會非常有用。比如，聯合型別和部分型別這兩個特性是非常有用的，它們可能是我最希望看到的兩個改進方向。
但我也認為，Kotlin 不必像 TypeScript 那樣做過多複雜的型別代數。有些 TypeScript 程式碼我覺得過於複雜，完全不必要。Kotlin 在這些基礎特性的完善上做得很好，應該繼續保持和改進。
另外，關於物件字面量，我認為可以考慮簡化其語法。對我來說，這感覺是語言中最不直觀的部分。每次寫物件字面量時，我總是需要記住它是不是寫對了。對於 Kotlin 中的其他部分，我幾乎不需要這樣反覆確認，所以這是我認為可以改進的地方。
最後，模式匹配也是一個值得關注的領域。實際上，Java 在模式匹配方面走在前面，甚至可能在這一方面進一步領先。我認為，Kotlin 在這個領域的提升會是一個很不錯的改進方向。
Márton：繼續擁抱 Java 生態系統是非常重要的。未來 Kotlin 在這些方面的提升一定會帶來更好的體驗。
Rod：Scala 的社群曾有很多來自學術界的人，他們總是試圖把每件事做得非常複雜，追求“聰明”的做法，而這並不是 Kotlin 社群的特點。Kotlin 社群並沒有這個問題，大家更多關注的是實用性和可理解性，這一點非常好，我也希望這種文化能夠持續下去。Kotlin 語言本身似乎也沒有給人一種“透過做最複雜的事情來彰顯聰明才智”的感覺，這種專注於清晰和可讀性的氛圍是非常健康的。
Sebastian：你是否願意分享一下你正在做的專案是什麼？
Rod： 基本上，我在探索知識圖譜和 RAG 的相關工作。傳統的向量搜尋存在嚴重的限制，而嘗試從結構化和非結構化內容中提取知識圖譜，可能為 RAG 提供一種更優的替代方案。這對我來說非常有趣，因為首先，我認為可解釋性在現實世界的 AI 應用中至關重要。僅僅說“在那 1750 億個引數中有某種權重組合得出了這個答案”並不足夠，微調並不是解決 LLM 在實際使用中面臨的許多問題的答案。另外，我一直是圖資料庫和知識圖譜的忠實支持者，這在我看來是一個非常重要的領域。
另外，我也想說的是，人們不必非得使用 Python 來進行生成。實際上，我從 Python 轉到 Java 和 Spring AI 時，雖然當時我對 Python 非常熟悉，但轉到 Java 後，我發現自己在需要的工作中反而更加高效。而現在，當我使用 Kotlin 時，我的生產力又得到了提升。所以，雖然對於那些想從事生成領域的開發者來說，Python 是必需的（任何認真對待自己職業發展的開發者都必須能夠至少流利閱讀並能寫 Python），但如果他們在 JVM 上構建應用，且所在的組織也主要使用 JVM，那麼轉向 Python 並不總是最佳選擇。Spring AI 的進展非常好，你可以繼續使用你熟悉的技術，整合現有的庫和後端服務，而生成工作也能順利進行。
參考連結：
https://www.youtube.com/watch?v=Rx3XZoqbi78