自使用Java十五年后，我编写Kotlin的第一行到现在已经快五年了。我们的团队没有按照典型的Java剧本：我们用Utterlyidle代替Spring，拥抱了函数式编程方法Totallylazy。我们是IntelliJ的忠实拥护者，并试图充分利用它为Java提供的工具。
那时，我们已经在寻找Java以外的东西了。一些团队对Scala表现出了一定的兴趣，并且我们已经在其中编写了一些服务。但是，其复杂性，与Java代码库一起工作的痛苦以及缓慢的构建时间，使得该语言对我们大多数人不受欢迎。
当Google宣布Kotlin在2017年成为Android开发的官方语言时，与我们关系密切的另一个团队评估了该语言在其服务器端开发中的作用。最终，我们大多数人都尝试了一下。
Kotlin对我们的代码库的影响让我震惊。它感觉更有生产力，更安全，并且工具虽然还不如Java成熟，但足以使其值得采用。
摆脱一种古老而冗长的语言，并发现哪种编码风格与Kotlin的功能非常吻合，这也很有趣。与Java的出色互操作性意味着我们可以逐步依赖现有的生态系统和过渡系统，而不会对完成工作造成重大干扰。
不久，我对Kotlin的兴趣导致共同创建了http4k（用于Kotlin HTTP应用程序的功能性工具包），并运行了Real World Kotlin开发研讨会，以帮助尝试进行相同过渡的其他团队。
最终，我到了其他职位，但很幸运看到Kotlin在服务器端用于其他各种项目。我还亲身经历了很多原因，使得团队强烈不愿意采用Kotlin。
奇怪的是，抵制并不总是源于实际语言的优点。那么，为什么Java服务器端社区没有更广泛地采用Kotlin？
我和我的同事遇到的一些原因如下：
“我们没有时间学习一种新语言。”
健康的软件项目总是需要大量的学习。一个称职的Java开发人员可以在数小时内掌握Kotlin的基础知识，并且几天之内就可以相当高效地工作。
一旦生产力提高，当他们编写更简单的代码时，由于采用了新的语言，因此解决了较少的问题，这是一笔值得的投资。
“每个版本的Java都在不断完善。”
没错：Java越来越好。而且发布的速度更快。另一方面，在处理可空性等简单的事情上，它仍然落后于Kotlin。
也许Java社区已经习惯了该语言的发展速度。尽管如此，Kotlin提供了一种在今天而不是明天的项目中利用其中许多功能（以及更多功能）的方法。
“作为Java开发人员，我们感到很高兴。”
这种抵抗是最棘手的。如果程序员将他们的专业身份与一种编程语言联系在一起，那就无能为力了。
一方面，我了解Java开发人员是否不想通过跳入新语言的未知领域来赌博自己的职业。或者他们想成为长期专家。这很公平。
另一方面，我还没有看到Java开发人员“落后”，因为他们使用的是Kotlin。相反，这表明他们一直在寻找最适合自己工作的工具，这是一个积极的特征，至少在我帮助雇用的人身上。
“Kotlin是一门炒作高涨的语言，前景不明。”
这是我们在2017年左右遇到的普遍反对意见。在那一年，Google接受Kotlin作为Android开发的一流语言，从而使我们确信，大公司对这种语言的长久发展很感兴趣。
如今，鉴于诸如Spring和Micronaut之类的流行框架似乎已经接受了这种新语言，这种观点可能已经不那么普遍了。
希望这将使该语言具有足够的可视性，以供更多服务器端人员尝试。
“我正在使用Eclipse，并且不想切换到IntelliJ。”
可以公平地说，Eclipse中的Kotlin经验可能与JetBrains IDEA不符。
这是可以理解的，因为JetBrains的业务模型包括出售其开发人员工具。而且这不太可能很快改变。
对于这些，唯一的希望是Kotlin达到了一个临界点，这证明了对Eclipse支持进行进一步投资的合理性。在此之前，对于Kotlin开发人员而言，最佳的开发人员体验将保留在JetBrains产品上。
我非常有偏见的观点是，无论如何，IntelliJ已经是Java更好的IDE，因此值得尝试一下该开关。
“ Kotlin开发人员太昂贵了，很难获得。”
很难评估这一点：在薪金网站上，可以得出结论，科特林的薪水总体上略高。
如果我们只考虑服务器端开发人员，那将是一个艰难的比较。通常，这是Java领域中费用最高的领域，并且Kotlin方面没有足够的数据可比较。
有趣的是，在实践中，我们看到高级Java开发人员通常是最早采用Kotlin的人员，这可能给人以Kotlin开发人员昂贵的印象。
在招聘方面，我们还没有发现吸引Kotlin开发人员的问题。我们很清楚，这项工作需要使用新的语言，并接受开发人员将在工作中学习它。
这似乎使Java开发人员放心，并吸引了那些热衷于学习新事物的人，这也是潜在的契合度。
“Kotlin太复杂了。”
Kotlin之所以比Scala之类的语言更吸引人的原因之一是，它在开发人员的易用性和高级功能之间取得了不错的平衡，以使Java的可操作性和流行框架的采用成为可能。
在实践中，这种异议往往与各个团队的技能，风格和惯例有关。
初学者倾向于像编写Java一样开始编写Kotlin。随着他们对语言的适应性提高，他们可能会将某些函数（例如扩展和内联函数）推开了，从而使新手难以理解代码库。
在一个团队完全掌握新语言之前，我们强烈建议尽可能长时间使用Boring Kotlin（TM）。最终，大多数团队将足够舒适地在选择出色的语言功能和使整个团队都可以访问代码之间找到平衡。
“在一个代码库中使用两种语言令人困惑。”
那些没有在实际项目中尝试过Kotlin的人们普遍担心。
在实践中，只要团队参与并记住新的Kotlin代码首先需要与Java共存，则在单个项目中使用这两种语言不会带来很大的麻烦。
一个有用的规则是：“如果更改涉及两种语言，则首先将旧代码转换为Kotlin”。
这样，团队就可以避免大规模的重写，并逐步迁移他们需要增加新价值的领域。
如果Java中保留了一些代码，那也是可以的。这很可能是因为代码有效，并且没有迫切需要对其进行重构。
“我们对Java感到更自在。”
实际上，可能是给定的上下文不要求使用新语言。一切正常。团队正在以可接受的速度完成工作，并且很好地把握了Kotlin将帮助解决的问题。
但是，根据我们的经验，这是例外，而不是规则。通常，这种抵制来自普遍缺乏时间或对学习的兴趣，而不是缺乏需要改进的地方。
在尝试一个真实的项目之前，还很难体验到Kotlin的好处，并且引入一种新的语言（即使作为实验）也可能引起很多焦虑。
在这种情况下，我们建议您“在工作中学习”（以编码dojos，棕色皮包课程等形式）来创建一个安全的环境，在这种环境下可以进行此类实验。
这种方法使团队可以评估他们对Java的使用以及是否值得在Kotlin上进行投资。
“我不知道Kotlin会带来什么优势。”
有时，Java开发人员没有意识到语言限制，或者已经习惯了它们。在其他时候，他们会忽略任何使他们质疑当前选择语言的选择。
无需赘述，可以说Kotlin的简洁性和安全性是它的主要优势。但是，有些人会声称他们没有看到Java的冗长性问题，并且已经编写了安全的代码。
在尝试使用Kotlin之前将其放弃很容易，而且面对这种选择时，一些人会继续寻找不尝试的理由。
最后的想法
对于大多数团队而言，采用一种新的编程语言（尤其是在进行中的项目中）会带来挑战。同样重要的是，要接受对变革的抵制是高度特定于上下文的，并且来自项目需求和个人原因，以及语言本身。
话虽如此，我仍然鼓励更多的Java服务器端开发人员在有机会的情况下尝试Kotlin。