为什么 Java 后端开发没有大规模采用 Kotlin？

你知道的越多，不知道的就越多，业余的像一棵小草！

成功路上并不拥挤，因为坚持的人不多。

编辑：业余草

juejin.cn/post/6844904122160775176

推荐：https://www.xttblog.com/?p=5221

今年以来，公司来了不少新同事。其中有一位，推荐使用 Kotlin 编写部分微服务程序。在各方考虑之后，婉拒了使用 Kotlin 的方案。本文分析一下，为什么 Kotlin 并没有比想象中的强！

在使用了 Java 15 年后，我写了第一行 Kotlin 代码，到现在已经差不多 5 年了。我们的团队用 Utterlyidle 替代 Spring，用 Totallylazy 进行函数式编程。我们是 IntelliJ 的忠实粉丝，并试着充分利用它提供的 Java 工具。

那个时候，我们不只使用 Java。有一些团队对 Scala 感兴趣，并用它开发了一些服务。但是，因为 Scala 与 Java 代码库协作的复杂性以及缓慢的构建时间，对于我们大多数人来说，它并没有太大吸引力。

2017 年，谷歌宣布 Kotlin 成为 Android 的官方开发语言，另一个与我们关系密切的团队开始评估是否可以在他们的服务器端开发中使用它。最后，我们大多数人都去尝试了一下。

我被 Kotlin 给代码库带来的影响震撼到了。它给人的感觉是更高效、更安全，虽然开发工具没有 Java 那么成熟，但也足够好了。

从一门陈旧而冗长的编程语言中解脱出来，并探索哪些编码风格更适合 Kotlin 的特性，这本身就是一件非常有趣的事情。Kotlin 与 Java 出色的互操作性意味着我们可以增量地依赖现有的生态系统和过渡系统，而不会对工作造成重大干扰。

很快，由于对 Kotlin 的兴趣，我们一起开发了 http4k，一个用于开发 Kotlin HTTP 应用程序的工具包，并组织了 Kotlin 开发研讨会，帮助其他团队尝试使用 Kotlin。

最后，我们看到其他各种项目也在服务器端使用 Kotlin，也看到了一些团队强烈不愿意采用 Kotlin 的原因。

有意思的是，这种抗拒并不总是因为编程语言本身。那么，为什么 Java 服务器端开发社区没有更多地采用 Kotlin 呢？

以下是我和我的同事们看到的一些原因。

我们没有时间学习一门新语言

这也就是我们在软件开发项目当中经常看到的“忙着砍柴没时间磨斧子”现象。这通常预示着更深层次问题，比如不断增加的技术债务和开发效率问题。

健康的软件项目需要开发者花大量时间去学习。一个有能力的 Java 开发者可以在数小时内掌握 Kotlin 的基本知识，并在数天内提高开发效率。

如果采用新语言可以让他们写的代码更简单，遇到的问题更少，那么投入就是值得的。

Java 的每一个版本都在变得更好

这是真的，Java 正在变得更好，而且发布的速度也越来越快。但是，对于处理空值这么简单的事情，仍然远远落后于 Kotlin。

也许 Java 社区已经习惯了这种演化速度。尽管如此，Kotlin 还是提供了一种方法，可以在项目中用上很多 Kotlin 特性。

作为 Java 开发者，我们感到很自豪

这种想法是最要命的。如果一个程序员把他们的专业身份和一种编程语言联系在一起，那就没有办法了。

如果说 Java 开发者不想赌上自己的事业踏入一门新语言的未知领域，我可以理解。或者他们可能想成为一个领域的专家，这也很合理。

但是，我也并没有看到哪个 Java 开发者因为使用 Kotlin 而“落后”了。相反，这表明他们一直在寻找适合自己的工具，这是一种积极的特质。

Kotlin 是一种被炒作的语言，它的未来是未知的

这是我们在 2017 年经常听到的反对采用 Kotlin 的说法。在那一年，谷歌宣布将 Kotlin 作为 Android 的官方开发语言，让我们确信科技巨头们对这门语言是感兴趣的。

现在，Spring 和 Micronaut 等流行框架似乎已经接受了这门新语言，之前的反对声就不那么经常听到了。

希望这能让更多的服务器端开发对这门语言有足够的了解，并尝试一下。

我正在使用 Eclipse，不想切换到 IntelliJ

在 Eclipse 中使用 Kotlin 的体验与 JetBrains 的 IDEA 不太一样。

这是可以理解的，因为销售开发工具是 JetBrains 的商业模式之一，而且这种情况短期内不太可能改变。

对于这些人来说，他们能够期望的是 Kotlin 可以达到一个质量临界点，证明 Eclipse 为它提供进一步的支持是值得的。但在此之前，对于 Kotlin 开发者来说，最好的开发体验仍然是使用 JetBrains 产品。

我认为，IntelliJ 已经是一个更好的 Java IDE 了，所以它也值得一试。

Kotlin 开发者太贵了，而且很难招到

这一点很难说，从招聘网站的数据来看，Kotlin 开发者的薪资总体上略高一些。

如果我们只考虑服务器端开发者，就很难进行比较。一般来说，Java 开发者的薪资是最高的，但在 Kotlin 方面并没有足够的数据来进行比较。

有趣的是，在实际当中，我们可以看到高级 Java 开发者经常是率先采用 Kotlin 的人，这可能会给人留下 Kotlin 开发者很“贵”的印象。

在招聘方面，我们并没有觉得很难招到 Kotlin 开发者。我们很清楚，有些工作需要使用这门新语言，并允许开发者在工作中边学边用。

这似乎让 Java 开发者放下心来，并吸引了那些热衷于学习新事物的人。

Kotlin 太复杂了

Kotlin 之所以成为 Scala 等语言的替代语言，其中一个原因是它在易用性和高级特性之间取得了良好的平衡，与 Java 具有更好的互操作性，所以更有可能被流行框架采用。

在实际当中，这种反对声与团队的技能、风格和习惯有关。

初学者一般会像使用 Java 一样使用 Kotlin，但随着他们越来越熟悉这门语言，可能会深入使用一些特性(例如扩展和内联函数)，从而导致代码库变得越来越难以理解。

在团队完全掌握新语言之前，我们建议尽可能长时间地使用普通的 Kotlin 特性。最后，团队中的大多数人都会在选择很酷的语言特性和保持代码库易于理解之间找到平衡点。

在一个代码库中使用两种语言让人感到困惑

这是在实际项目中没有尝试过 Kotlin 的人经常会有的担忧。

在实际当中，当团队意识到新的 Kotlin 代码需要与 Java 共存，那么在一个项目中使用两种语言并不会给他们造成很大的痛苦。

这里有一个有用的规则：“如果一个变更涉及到两种语言，首先将旧代码转换成 Kotlin”。

这样，团队就可以避免大爆炸式的重写，并将需要添加新特性的地方进行逐步迁移。

如果需要保留一些 Java 代码，那也没关系。很有可能是因为这些代码仍然有用，并且没有进行重构的迫切需求。

我们更喜欢 Java

在实际当中，有一些场景不一定要使用 Kotlin，一切仍然能够进行得很顺利，团队能够以可接受的速度完成工作。

然而，根据我们的经验，这是例外，而不是常态。通常情况下，这种对语言的抗拒源于缺少时间和兴趣，而不是因为没有可提升的空间。

如果没有在真正的项目中使用 Kotlin，是也很难体会到 Kotlin 的好处的。即使是作为一个实验，也存在很多焦虑。

对于这种情况，我们建议“在工作中边学边用”(以编码道场、培训等形式)，创造一个可以进行这种实验的安全环境。

这样可以帮助团队评估他们对 Java 的使用状况，以及是否值得在 Kotlin 上投入。

我看不出 Kotlin 会带来什么好处

有时候，Java 开发者意识不到语言方面存在的限制，或者是因为他们已经习惯了。有时候，他们会抗拒新语言，因为新语言会让他们质疑自己正在使用的语言。

在不深入细节的情况下，我们可以说 Kotlin 的简洁性和安全性是它的主要优点。然而，有些人声称他们不认为 Java 的冗长有什么问题，并且写出来的代码也很安全。

在真正去尝试 Kotlin 之前，人们很容易将其忽略掉。而在真正面对它的时候，一些人会继续寻找不尝试使用它的理由。

一些想法

采用一种新的编程语言，特别是在正在进行的项目当中，这对于大多数团队来说都是一个挑战。对变化的抗拒与特定的环境有关，与项目需求和个人原因以及语言本身也有关。

话虽如此，我仍然鼓励更多从事 Java 服务器端的开发者，如果有机会的话，可以尝试一下 Kotlin。