在Java十五年之后，我写了第一本Kotlin书已经快五年了。我们的团队没有遵循典型的Java剧本：我们使用Utterlyidle而不是Spring，并采用Totallyazy方法进行函数式编程。我们是IntelliJ的忠实粉丝，并尝试充分利用它为Java提供的工具。那时候，我们的目光已经超越了Java。有一些团队对Scala感兴趣，我们在里面写了一些服务。但是使用Java代码库的复杂性、痛苦和缓慢的构建时间使该语言对我们大多数人没有吸引力。当谷歌在2017年宣布Kotlin将成为Android开发的官方语言时，另一个与我们关系密切的团队在他们的服务器端开发中评估了该语言。最终，我们大多数人都会尝试一下。Kotlin对我们的代码库产生的影响令我震惊。它感觉更高效、更安全，而且这些工具虽然不如Java成熟，但足以让我们值得采用。摆脱陈旧冗长的语言并发现哪些编码风格非常适合Kotlin的特质也很有趣。与Java的出色互操作性意味着我们可以逐步依赖现有的生态系统和过渡系统，而不会严重中断工作的完成。我很快对Kotlin产生了兴趣，与人共同创立了http4k，一个KotlinHTTP应用程序的功能性工具包，并举办了“RealWorldKotlinDevelopmentWorkshops”来帮助其他团队进行同样的转型。最终，我转到了其他角色，但我很幸运地看到Kotlin在其他各种项目的服务器端使用。我亲身体验过为什么有些团队非常不愿意采用Kotlin。奇怪的是，阻力并不总是来自实际的语言利弊。那么，为什么Kotlin没有被Java服务器端社区更大程度地采用呢？我和我的同事遇到的一些原因如下：我们没有时间学习一门新语言。,busysharpeninganax”变体。这通常是更深层次问题的征兆，例如不断增加的技术债务和一般生产力问题。健康的软件项目总是需要大量的学习。而称职的Java开发人员可以掌握Kotlin的基础知识几个小时，并在几天内相当高效。当他们编写更简单的代码并处理更少的问题时，新语言带来的生产力提高是一项值得的投资。的确，每个版本的Java都在变得更好：Java越来越好。而且发布速度越来越快。另一方面，在处理空等简单的事情上，它仍然远远落后于Kotlin。也许Java社区已经习惯了该语言的发展速度。尽管如此，Kotlin还是提供了一种在项目中利用这些（以及更多）功能的方法。作为Java开发人员，我们很高兴这种阻力是最棘手的。如果一个程序员将??他的职业身份与一种编程语言联系在一起，他就无能为力了。一方面，如果Java开发人员不想拿自己的职业生涯做赌注，跳入一门新语言的未知领域，我可以理解。或者他们想成为一名长期专家，这很公平。另一方面，我还没有看到Java开发人员因使用Kotlin而“落后”。相反，它表明他们一直在为他们的工作寻找最好的工具，这是一个积极的特征，至少对于我帮助招募的人来说是这样。Kotlin是一门被炒得沸沸扬扬、前途未卜的语言这是我们在2017年左右看到的普遍反对意见。那一年，Google接受了Kotlin作为Android开发的一流语言，我们可以放心，大玩家们都对它感兴趣这种语言的长期发展。这在今天可能不太常见，因为像Spring和Micronaut这样的流行框架似乎已经接受了这种新语言。希望这会给该语言足够的知名度，让更多的人在服务器端试用它。我正在使用Eclipse，不想切换到IntelliJ公平地说，Eclipse中的Kotlin体验可能无法与JetBrainsIDEA相媲美。这是可以理解的，因为JetBrains的商业模式包括销售其开发者工具。而且这不太可能很快改变。他们唯一的希望是Kotlin达到临界质量，证明进一步投资Eclipse支持是合理的。在那之前，JetBrains产品将为Kotlin开发人员提供最佳的开发体验。我的观点是IntelliJ已经是一个更好的JavaIDE，所以也值得一试。Kotlin开发人员太贵且难以获得难以评估这一点：在薪资网站上，可以得出结论，Kotlin的薪水总体上略高。如果我们只考虑服务器端开发人员，则很难进行比较。总的来说，那是Java薪水最高的领域，Kotlin上没有足够的数据可以比较。有趣的是，我们在实践中看到高级Java开发人员往往是Kotlin的早期采用者，这可能给人一种Kotlin开发人员成本高昂的印象。在招聘方面，我们没有发现吸引Kotlin开发人员的问题。我们认识到工作需要新的语言，并接受开发人员在工作中学习新的语言。这似乎让Java开发人员放心并吸引了那些热衷于学习新东西的人，这是一个潜在的恰当指标。Kotlin太复杂了Kotlin成为像Scala这样的语言的令人信服的替代品的原因之一是它在开发人员易用性和高级功能之间取得了适当的平衡，使其可以与Java的可靠性相媲美。流行框架的可操作性和采用是可能的。在实践中，这种分歧通常与各个团队的技能、风格和惯例有关。初学者倾向于像编写Java一样开始编写Kotlin。随着他们对这门语言越来越熟悉，他们可能会将某些功能（例如扩展和内联函数）推得太远，使新手难以理解代码库。我们强烈提倡尽可能长时间地使用BoringKotlin(TM)，直到团队完全适应新语言。最终，大多数团队在选择很酷的语言特性和让整个团队都可以使用代码之间找到了平衡。在一个代码库中使用两种语言令人困惑那些没有在真实项目中尝试过Kotlin的人普遍关心的问题。实际上，在一个项目中使用两种语言并不是什么明显的痛苦，只要团队同意并注意到新的Kotlin代码首先需要与Java共存。一条有用的规则是：“如果更改涉及两种语言，请先将旧代码转换为Kotlin”。这允许团队避免大量重写，而是逐渐迁移到需要添加新价值的地方。一些代码是否保留在Java中并不重要。很可能是因为代码仍然有效并且没有重构的迫切需要。我们在实践中对Java感觉更舒服，可能是特定的上下文不需要新的语言。一切都很好;团队以可接受的速度完成工作，并且很好地掌握了Kotlin将帮助解决的问题。然而，根据我们的经验，这是例外而不是规则。通常情况下，这种阻力源于普遍缺乏学习时间或兴趣，而不是缺乏需要改进的地方。在实际项目中尝试使用Kotlin之前，也很难理解Kotlin的好处，引入一种新语言，即使是作为实验，也会引起很多焦虑。在这些情况下，我们建议进行“在职学习”（以编码道场、BrownPack课程等形式），以创造一个可以进行此类实验的安全环境。这种方法允许团队评估他们对Java的使用以及是否值得投资Kotlin。不知道Kotlin带来了什么优势。有时，Java开发人员不知道该语言的局限性，或者已经习惯了它们。其他时候，他们拒绝任何让他们质疑当前选择的语言选择。不赘述，可以说Kotlin的简单性和安全性是它的主要优势。不过，有些人会说，他们不认为Java的冗长是个问题，写出来的代码已经很安全了。在尝试之前很容易否定Kotlin，当面临选择时，一些人会继续找理由不去尝试。最后的想法采用一种新的编程语言，尤其是在正在进行的项目中，对大多数团队来说都是一个挑战。同样重要的是要接受这样一个事实，即对变化的抵制是非常具体的，它将来自项目需求和个人原因以及语言本身。话虽如此，我仍然鼓励更多从事Java服务器端工作的开发人员在有机会的情况下尝试使用Kotlin。如果没有其他原因，它可能会突出显示代码之外的其他改进领域。
