通过多次的实践，Kotlin在服务器端的采用速度很慢。然而，在某些具体情况下，避免收养是完全合理的。
使用 Java 超过 15 年之后， 我写了第一行Kotlin代码， 现在已经快五年了。
我们的团队没有遵循典型的 Java 规范： 我们使用Kotlin代替Spring， 并采用功能编程方法与完全敏捷开发。我们是 IntelliJ 的忠实粉丝，并试图充分利用它的智能为 Java 提供的便捷。
那时，我们已经把目光投向了Java以外的语言。一些团队对 Scala 有些兴趣，我们已经在其中写了一些服务。但是，与 Java 代码库一起配合工作的复杂性、痛苦和缓慢的构建时间使我们大多数人对语言没有耐心。
当谷歌在2017年宣布Kotlin将成为Android开发的官方语言时，另一个接近我们的团队评估了其服务器端开发的语言。最终，我们大多数人都在尝试它Kotlin。
Kotlin对我们的代码库的影响让我大为震撼。它感觉更有生产力，更安全，而且这种手法，虽然没有Java的成熟，但足以让采用,并且完全是值得的一用的。
离开一种感觉古板而冗长的语言，发现那些编码风格与 Kotlin 的功能非常契合，也很有趣。与 Java 出色的互操作性意味着我们可以逐步依赖现有的生态系统和过渡系统，而不会对完整的工作造成重大干扰和困惑。
很快，我对Kotlin的兴趣产生了共同创建http4k，Kotlin的HTTP应用程序的功能工具包，并且作用到真实场景。我们召开了Kotlin开发的研讨会，以帮助其他团队试图作出同样的过渡，并且会告诉他们带来了哪些优势。
最终，我迁移到这门新语言Kotlin，但很幸运地看到 Kotlin 在服务器端用于其他各种项目。我也亲身经历过一些原因， 有一些团队非常不愿意采用Kotlin。
但是令人好奇的是，阻力并不总是来自实际语言的一些缺点。那么，为什么Java服务器端的一些开发社区并没有令人一新的采用Kotlin呢？
以下是我和我的同事遇到的一些原因：
我们没有时间学习新语言。
这是我们在软件项目中经常看到的"忙着砍柴，不能磨斧头"的标题。这通常是技术债务不断增加和一般生产力问题等更深层次问题的迹象。
健康的软件项目总是涉及相当数量的学习。一个称职的 Java 开发人员可以在数小时内获得 Kotlin 的基本知识，并在几天内获得合理的生产力。
一次有价值的投资，一旦生产力的提高开始，当他们写更简单的代码处理较少的问题，因为新的语言，但确实是需要牺牲一些东西的。
Java在每一个版本中都变得越来越好。
确实如此： Java越来越好。发布的速度也更快。但是另一方面，在处理可控性等简单事情上，它仍然远远落后于Kotlin。
也许Java社区已经习惯了语言的进化速度。尽管如此，Kotlin 还是提供了一种方法，可以利用当今而不是以后的项目中的许多这些功能（以及更多）。
作为 Java 开发人员，我们很高兴。
这种阻力是最棘手的。如果程序员将他们的专业身份与单一编程语言联系在一起，人们就无能为力了。
一方面，我明白如果Java开发者不想通过跳入新语言的未知领域来赌他们的职业生涯。或者他们想成为一名长期专家。这很公平。
另一方面，我还没有看到一个Java开发人员是因为他们使用Kotlin而落后的。相反，这表明他们一直在寻找最好的工作工具，这是一个积极的特点，至少在我帮助招聘的人身上是这样。
Kotlin是一种炒作的语言， 前途不明。
这是我们在2017年左右看到的常见反对意见。在那一年，谷歌将Kotlin作为Android开发的一流语言，让我们放心，大玩家对语言的寿命感兴趣。
今天，这可能不太常见，因为像Spring和Hibernate这样的流行框架似乎已经接受了这种新语言。
希望这能给语言足够的可见性，让更多的服务器端的人给它一个尝试。
我正在使用Eclipse，不想切换到Intellij IDEA。
公平地说， Kotlin在 Eclipse 的经历可能与实际很多不同。
这是可以理解的，因为Eclipse的商业模式包括销售他们的开发人员工具。这种情况不太可能很快改变。
唯一的希望是Kotlin达到更高的质量， 证明对 Eclipse 支持的进一步投资是正当的。在此之前，Kotlin开发人员的最佳开发人员体验将保留在 JetBrains 产品上。
我非常有偏见的观点是，IntelliJ已经是一个更好的Java IDE，所以它可能值得给开关尝试太多。
Kotlin的开发商太贵了，很费钱
这一个是很难评估的：看看主流的招聘网站，人们可以得出结论，Kotlin的工资整体略高。
如果我们只考虑服务器端开发人员，则很难进行比较。一般来说，这是支付最高的Java的一些专家，没有足够的数据在Kotlin方面进行比较。
传闻，我们看到，在实践中，高级Java开发人员往往是第一个采用Kotlin，这可能给人的印象是，Kotlin开发商是昂贵的。
在招聘方面，我们还没有看到吸引 Kotlin 开发人员的问题。我们很清楚，这项工作需要使用新的语言，并接受开发人员将在工作中学习它。
这似乎让 Java 开发人员放心，并吸引那些热衷于学习新事物的人，这也是潜在适合的一个很好的指标。
Kotlin太复杂了。
Kotlin 之所以成为 Scala 等语言的有力替代品，原因之一是它在开发人员易用性和高级功能之间达成了体面的平衡，使 Java 的可操作性和流行框架的采用成为可能。
实际上，这种反对往往与个别团队的技能、风格和惯例有关。
初学者往往开始写科特林， 就像他们写Java一样。随着他们对语言越来越适应，他们可能会将一些功能（如扩展和内联功能）推得太远，使代码库对新来者来说难以理解。
在团队完全胜任新语言之前，我们强烈主张尽可能长时间地使用无聊的Kotlin （TM）。最终，大多数团队将足够舒适，能够在选择酷的语言功能和让整个团队都能访问代码之间找到平衡点。
在一个代码库中使用两种语言是令人困惑的
这是那些没有在真正的项目中尝试过Kotlin的人的普遍恐惧。
在实践中，只要团队在开发的过程中，并意识到新的 Kotlin 代码首先需要与 Java 共存，在单个项目中使用两种语言不会带来重大痛苦。
一个可以帮助的规则是："如果触摸两种语言的更改，首先从将旧代码转换为 Kotlin 开始"。
这样，团队就可以避免大面积的重写，并逐步迁移他们需要增加新的有价值的领域。
如果一些代码仍保留在Java中，那也没关系。最有可能的是，这是因为代码的工作原理，并没有迫切需要重新构想它。
我们使用Java更舒适。
在实践中，可能是给定上下文不需要新语言。一切正常：团队正在以可接受的速度完成工作，并很好地掌握了Kotlin将帮助解决的问题。
然而，根据我们的经验，这是例外，而不是规则。这种抵制往往源于对学习的普遍缺乏时间或兴趣，而不是缺乏改进的领域。
也很难体验到Kotlin的好处，直到尝试一个真正的项目，并引入一种新的语言，即使作为一个实验，可以引起很多焦虑。
在这些情况下，我们建议"在工作中学习"（以编码道场、沙箱会话等形式）来创造一个安全的环境，让这种实验得以进行。
这种方法允许团队评估他们使用 Java 以及是否值得在 Kotlin 投资。
我不明白Kotlin会带来什么好处。
有时 Java 开发人员不知道语言限制或太习惯语言限制。其他时候，他们会拒绝任何让他们质疑他们当前选择的语言的替代方案。
在不详情的情况下，我们可以说Kotlin的简洁和安全是其主要优点。然而，有些人会声称他们没有看到Java的冗长问题，并且已经编写了安全代码。
在尝试之前，很容易将Kotlin拍死掉，当面对这个选择时，一些人会继续寻找不尝试的理由。
最终想法
采用新的编程语言，特别是在正在进行的项目中，对大多数团队构成挑战。同样重要的是要接受，对变革的抵制是高度针对上下文的，将来自项目需求和个人原因，以及语言本身。
话虽如此， 我仍然鼓励更多的开发人员在 Java 服务器侧工作， 给 Kotlin 一个尝试， 如果他们有机会。如果没有别的，它可能会突出其他改进领域超越代码。
