Google 宣布 Kotlin-first 已四年，为什么 Java 开发者仍不买账？

Posted 2021-06-12 xhmj12

【编者按】2017 年 Google I/O 大会上，Google 重磅宣布 Kotlin 正式成为 android 的开发一级语言，然而，如今经过四年的时间，据SlashData 最新发布的《开发者报告》显示，当前使用 Java 构建应用程序的移动开发人员依旧是 Kotlin 的两倍，在研究为何 Kotlin 如此不受欢迎，以及 Java 程序员为何抗拒 Kotlin 时，一位资深 Java 开发者列出了 10 大理由。

以下为译文：

由于开发人员的自我满足、职业保护、以及 Kotlin 的自我宣传不足，我在外面世界看到的真实情形是：服务器端对 Kotlin 的采用速度非常缓慢。尽管在某些特定场景下，不采用完全有合理的理由。

在使用 Java 超过 15 年后，我开始使用 Kotlin 进行编程，而现在时间已经过去快 5 年了。

我们的团队没有遵循典型的 Java 手册：我们使用 Utterlyidle 替代了 Spring，并采用了 Totallylazy 的函数式编程方法。我们是 IntelliJ 的忠实拥护者，并尽量充分利用它为 Java 提供的一切工具。

那时，我们已经在寻找 Java 以外的编程语言了。一些团队对 Scala 表现出了一定的兴趣，并且已经用它编写了一些服务。但是，由于其复杂性、和 Java 代码库协同工作的痛苦、以及缓慢的构建时间，这个语言对我们大多数人而言，很快失去了吸引力。

当谷歌在 2017 年宣布 Kotlin 将成为 Android 开发的官方语言时，与我们关系密切的另一个团队对该语言在其服务器端开发中的作用进行了评估。最终，我们大多数人都尝试了一下。

Kotlin 对我们代码库的影响令我震惊。它让人感觉更高效、更安全，而且其工具虽然没有 Java 那么成熟，但也足以让它值得被采用。

摆脱一种古老而又冗长的语言，并发现什么样的编码风格与 Kotlin 的特性非常吻合，也是一件很有趣的事情。Kotlin 与 Java 出色的互操作性意味着我们可以增量地依赖现有的生态系统和过渡系统，而不会对完成工作造成重大干扰。

很快，我就对 Kotlin 产生了兴趣，并且共同创建了 http4k，这是一个用于开发 Kotlin HTTP 应用程序的函数式工具包，我们举办了“真实世界 Kotlin 开发研讨会”，以帮助其他团队进行同样的转型。

最终，我转到了其他岗位。但是很幸运，我看到了各种各样的项目开始在服务器端使用 Kotlin。也亲身经历了一些团队强烈不愿意采用 Kotlin 的原因。

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

以下是我和同事们遇到的一些原因：

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

这是我们在软件项目中常见的“忙于砍树，没时间磨斧子”的现象。这通常预示着项目中存在更深层次的问题，比如不断增加的技术债务和一般的开发效率问题。

健康的软件项目总是需要开发者投入相当多的时间去学习。一个有能力的Java开发人员可以在数小时内掌握 Kotlin 的基本知识，并且在几天内就可以相当高效地开发。

如果采用新语言可以让他们写的代码更简单，遇到的问题更少，开发效率就会得到提高，那么这种投入就是值得的。

2、Java 的每一个版本都在不断完善

这是事实：Java 正在变得更好。而且发布的速度也越来越快。然而，另一方面，对于处理像 Nullability 这么简单的事情，Java 仍然远远落后于 Kotlin。

也许Java社区已经习惯了这种语言的发展速度。尽管如此，Kotlin还是提供了一种方法，可以在今天而不是明天的项目中利用这些特性（以及更多）。

3、作为 Java 开发人员，我们很自豪

这种阻力是最棘手的。如果一个程序员把自己的职业身份和一种编程语言联系起来，那就无能为力了。

如果说，Java 开发人员不想赌上自己的职业生涯，而踏入一种新语言的未知领域。这一点我可以理解。或者他们想成为一名长期专家。这一点也很合理。

然而，在另一方面，我并没有看到哪个 Java 开发人员因为使用 Kotlin 而“落后”了。相反，这表明他们一直在为自己的工作寻找最好的工具，这是一个积极的特质，至少对我帮助招聘到的人来说是这样。

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

这是我们在2017年前后经常听到的一个反对采用Kotlin的说法。在那一年，谷歌宣布将Kotlin作为Android的官方开发语言，从而使我们相信，大公司对这种语言的长久发展很感兴趣。

今天，这种反对声音不那么经常听到了，因为Spring和Micronaut等流行框架似乎已经接受了这门新语言。

希望这能给这门语言带来足够的知名度，让更多的服务器端开发人员尝试一下

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

公平地说，在 Eclipse 中使用 Kotlin 的体验可能与 JetBrains 的 IDEA 不太一样。

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

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

我个人则倾向认为（可能有点偏见），IntelliJ 已经是一个很好的 Java IDE 了，所以它也值得一试。

6、Kotlin 开发人员太贵了，而且很难招到

这一点很难评估：查看薪资网站上的薪资数据，可以得出结论，Kotlin 开发人员的薪资总体略高一些。

如果我们只考虑服务器端开发人员，那么这是一个很难比较的问题。一般来说，服务端开发属于 Java 开发人员中薪资最高的领域，然而 Kotlin 开发人员的薪资数据不够，无法进行比较。

有趣的是，我们在实际中经常看到，高级 Java 开发人员通常是最先采用 Kotlin 的人，这可能会给人一种 Kotlin 开发人员成本“昂贵”的印象。

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

这似乎让 Java 开发人员放下心来，并吸引了那些热衷于学习新事物的人，这也是一个潜在的合适指标。

7、Kotlin太复杂了

Kotlin 之所以能成为 Scala 等语言的替代语言，其中一个原因是它在开发人员的易用性和高级特性之间达成了一个很好的平衡，使其和Java具有良好的可操作性，从而被流行框架的采用成为可能。

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

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

在团队完全胜任新语言之前，我们强烈主张尽可能长时间地使用Boring Kotlin(TM)。最终，团队中的大多数人都可以很容易地在选择很酷的语言特性和保持代码库易于理解之间找到平衡点。

8、在一个代码库中使用两种语言令人困惑

对于没有在实际项目中尝试过 Kotlin 的人来说，这是一个普遍的担忧。

在实践中，只要团队所有人都意识到新的 Kotlin 代码首先需要与 Java 共存，那么在一个个项目中使用这两种语言不会带来很大痛苦。

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

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

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

9、我们对Java感到更自在

在实践中，有一些特定的场景不一定需要一门新语言，旧的语言可以很好地工作；团队能够以可以接受的速度完成工作，并且对 Kotlin 将要帮助解决的问题有很好的把握。

然而，根据我们的经验，这是例外，而不是常态。更多的时候，这种对新语言的抗拒往往源于缺乏学习时间和兴趣不足，而不是缺乏需要改进的地方。

在尝试一个真正的项目中使用 Kotlin 之前，是很难体验到 Kotlin 的好处的。引入一种新语言，即使是作为一个实验，也会引起很多焦虑。

对于这种情况，我们建议“在工作中边学边用”（以编码道场、午餐研讨会等形式），以创造一个安全的环境，让这种实验得以发生。这种方法允许团队评估他们对Java的使用情况，以及是否值得投资于Kotlin。

10、我看不出Kotlin会带来什么优势

有时候，Java开发人员意识不到语言的局限性，或者因为太习惯于这些局限性。在其他时候，他们会拒绝任何新语言，因为新语言会让他们质疑他们正在使用的语言。

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

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

11、最后的想法

采用一种新的编程语言，特别是在正在进行的项目中，对大多数团队来说都是一个挑战。同样重要的是要接受这样的事实，即对变化的抵触与具体情况密切相关，它来自于项目需求和个人原因、以及语言本身。

话虽如此，我仍然鼓励更多从事Java服务器端的开发人员，如果有机会的话，可以尝试一下 Kotlin。撇开其他不谈，它也可能会让你知道代码以外的其他改进地方。

转自：英文：Ivan Sanchez，翻译：CSDN