我们的团队没有遵循典型的Java手册：我们使用Utterlyidle而不是Spring，并采用Totallylazy的函数式编程方法。我们是IntelliJ的忠实拥护者，并试图充分利用它为Java提供的工具。
那时，我们的眼光已经超越了Java。有一些团队对Scala感兴趣，我们已经用它编写了一些服务。但是，与Java代码库一起工作的复杂性、痛苦以及缓慢的构建时间，使得这种语言对我们大多数人都没有吸引力。
当谷歌在2017年宣布Kotlin将成为Android开发的官方语言时，另一个与我们关系密切的团队在他们的服务器端开发中评估了这种语言。最终，我们中的大多数人都尝试了一下。
Kotlin对我们代码库的影响令我震惊。它让人感觉更有成效，更安全，而且工具虽然没有Java那么成熟，但也足以让我们值得采用。
从感觉陈旧和冗长的语言中解脱出来，并发现哪些编码风格非常适合Kotlin的特性，也是一件有趣的事情。与Java的出色互操作性意味着我们可以增量地依赖现有的生态系统和过渡系统，而不会对完成工作造成重大干扰。
很快，我就对Kotlin产生了兴趣，共同创建了http4k，一个用于Kotlin HTTP应用的函数式工具包，并举办了“真实世界Kotlin开发研讨会”，帮助其他团队进行同样的转型。
最终，我已经转到了其他岗位，但很幸运地看到了Kotlin在其他各种项目的服务器端的应用。而我也亲身经历了一些团队强烈不愿意采用Kotlin的原因。
很奇怪的是，阻力并不总是来自于实际语言的优劣。那么，为什么Java服务器端社区没有更大程度地采用Kotlin呢?
我和我的同事遇到的一些原因如下：
我们没有时间学习一种新语言
这就是我们在软件项目中常见的“忙着砍柴，忙着磨斧头”的变种。这通常是更深层次问题的征兆，如不断增加的技术债务和一般的生产力问题。
健康的软件项目总是需要相当数量的学习。而一个称职的Java开发人员可以在几个小时内掌握Kotlin的基础知识，并在几天内就会有合理的生产力。
当他们写出更简单的代码和处理更少的问题时，因为新的语言而提高生产力，这是一项值得的投资。
每个版本的Java都在不断完善
这是真的：Java正在变得更好。而且发布的速度也越来越快。另一方面，在处理空性这样的简单事情上，它仍然远远落后于Kotlin。
也许Java社区已经习惯了这种语言的发展速度。尽管如此，Kotlin仍然提供了一种方法，可以在他们的项目中利用这些特性中的许多(以及更多)。
作为Java开发人员，我们感到很高兴
这种阻力是最棘手的。如果一个程序员把自己的职业身份绑在单一的编程语言上，那就没什么办法了。
一方面，如果Java开发人员不想赌上自己的事业，跳进一门新语言的未知领域，我可以理解。或者他们想成为一名长期的专家，这很公平。
另一方面，我还没有看到Java开发人员因为使用Kotlin而“落后”。相反，这表明他们一直在寻找适合自己工作的最佳工具，这是一个积极的特质，至少对我帮助招聘的人来说是这样。
Kotlin是一门炒作高涨的语言，前途未卜
这是我们在2017年前后看到的一个常见的反对意见。在那一年，谷歌接受了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。随着他们对这门语言越来越熟悉，他们很可能会把一些功能(如扩展和内联函数)推得太远，使得代码库对新手来说难以理解。
在团队完全胜任新语言之前，我们强烈主张尽可能长时间地使用Boring Kotlin(TM)。最终，大多数团队都会在挑选很酷的语言特性和让整个团队都能使用代码之间找到平衡点。
在一个代码库中使用两种语言令人困惑
那些没有在实际项目中尝试过Kotlin的人们普遍担心。
在实践中，只要团队认同并注意到新的Kotlin代码一开始需要与Java共存，在一个项目中使用两种语言并不会带来明显的痛苦。
一个可以帮助的规则是："如果改动涉及到两种语言，首先要把旧的代码转换成Kotlin"。
这样一来，团队就可以避免大刀阔斧的重写，而逐步迁移需要增加新价值的地方。
如果有些代码还保留在Java中，那也没关系。很有可能是因为代码还能用，没有迫切的需要重构。
我们对Java感到更自在
在实践中，可能是特定的上下文不需要新的语言。一切都很好;团队以可接受的速度完成了事情，并且很好地掌握了Kotlin将帮助解决的问题。
然而，根据我们的经验，这是例外而不是常规。更多的时候，这种阻力源于普遍缺乏时间或学习兴趣，而不是缺乏需要改进的地方。
在尝试真正的项目之前，也很难体会到Kotlin的好处，引入一门新的语言，即使是作为实验，也会引起很多焦虑。
在这些情况下，我们推荐 "在职学习"(以编码dojos、布朗包会议等形式)，以创造一个安全的环境，让这种实验能够发生。
这种方法可以让团队评估他们对Java的使用和是否值得投资Kotlin。
我不知道Kotlin会带来什么优势
有时，Java开发人员不知道语言的局限性，或者太习惯于这些局限性。其他时候，他们会拒绝任何让他们质疑当前选择的语言的选择。
我们不细说，可以说Kotlin的简洁和安全是它的主要优势。然而，有些人会说他们不认为Java的啰嗦有问题，写出的代码已经很安全了。
在尝试之前很容易否定Kotlin，当面临选择时，少数人会继续寻找理由不尝试。
最后的想法
采用一种新的编程语言，尤其是在进行中的项目中，对大多数团队来说都是一种挑战。同样重要的是要接受这样的事实，即对变革的抵触情绪与具体情况密切相关，它将来自项目需求和个人原因以及语言本身。
说了这么多，我还是鼓励更多从事Java服务器端工作的开发者，如果有机会的话，可以尝试一下Kotlin。如果没有别的原因，它可能会突出代码之外的其他改进领域。
