在 Android 的世界，Kotlin 看起来无处不在。现在很难找到一个关于Android的会议或者一篇博客不提及 Kotlin。我记得在去年的柏林 Droid 会议，我所了解的大多数人都才开始在生产环境中使用 Kotlin (我也在两个月后发布了第一个更新)。确实，Kotlin 对 Android 开发社区的影响远远大于对 Java 开发社区的影响。我敢肯定 JetBrains 也一定未曾意料到这样的情况。
但是这是有道理的：从一开始，Android 的开发者就使用着过期的语言的过期版本，同时其他平台和语言在不断的演变。Kotlin 使得我们再次具有竞争力。
停步的信号
但是有时开发者的热情会被相关利益者控制。尽管 Kotlin 会为你的代码库和开发速度带来各种好处，但是很有可能没有机会使用 Kotlin。他们的很多理由可以很容易的驳回，但是有的则有一定道理。
我们一起来看看：
团队中的每一个人都需要学习一门新的语言
这个是一个明显有关的理由。但是好消息是：Kotlin 的学习曲线真的很低。
一开始你会用 Kotlin 的关键字写下 Java 风格的代码，这样就可以了，如果有问题，IDE 内置类复制粘贴转换功能。
举个栗子，相比之下，RxJava 的学期曲线则比 Kotlin 陡峭的多。
顺便说一下：你的团队在学习一门新的语言是一件好事情。
当然你需要找到一种方式让每一个成员都能够熟悉新的语言。这意味着时间，而对于利益相关者来说时间就意味着金钱。有一个很好且没有任何风险的开始点就是测试。测试是一个尝试新工具的安全环境。通过迁移测试环境开始或者用 Kotlin 来写一些新的测试。事实上，Kotlin 有一个很好的特性甚至会提高你的测试代码。过一段时间每一位成员都会了解 Kotlin 怎么工作，你也就可以进行下一步了。
很难找到有经验的 Kotlin 开发者
事实上，大多数开发者都渴望尝试新的事物，而那些不愿意尝试的也不是你想雇佣的。所以给候选者提供使用 Kotlin 的机会会增加录用他们的几率。
在 Swift 中我们可以验证这一点，现在已经很难找到喜欢使用 Objective C 的开发者，而 Swift 仅仅才发布3年。这个问题确实存在。请记住我们所处的世界：一个需要hr从现有项目中找出最佳人选的世界。我们所需要的职位远远多于开发者所适应的职位。用一种新的技术去筛选候选人是很好的寻找满意人选的方法，并将驱动你的产品前进。。。
Kotlin 没有 Google 的背书
这是事实，但是 Android 依赖于字节码。而来自 Kotlin 和 Java 的字节码最终是同一样东西。我们仅仅是在讨论我们写代码所使用的语言。Google 刚刚放弃了 Jack 工具链并且确认为了支持 Java8 提供 javac 编译器。所以前途是光明的。
在这里你真正需要关心的问题是，JetBrains 是否会为 Android 的 Kotlin背书。好消息，他们是坚定的。这是一个成功的故事并且需要耗费很大的精力才能走到现在。上一次 Android Studio 的一个 canary(!) 版本在 Kotlin 支持的方面出现了一些问题，第二天在 Kotlin 插件中就提供了修复。
将 Kotlin 应用到生产中的应用太冒险了
用 Kotlin 开发的应用在运行时没有任何风险。前面已经讲到，语言最终会转换成字节码。也许你正在使用的第三方库的更新风险都比添加Kotlin的风险要大，更何况像 Null Safety 这样的特性会使你的代码库更安全。
此外 Kotlin 已经不再是一门新的语言。从它的第一个功能发布到现在已经有一段时间了，现在已经稳定。
很多拥有大量用户的公司已经部分或者全部切换到 Kotlin。
这仅仅是另一门 JVM 语言而已
以前你可以用任意一种 JVM 语言来开发 Android 应用，但是没有人这么做，为什么我们现在就可以？
我记得以前有人尝试用 Scala 来开发 Android 应用，但是确实非常头疼，因为你需要发布运行库。
Kotlin 在设计时就有考虑 Android，运行库非常小。你所使用的大多数库都要比它大得多。这就是最大的不同！
我们没有时间重写应用
你不需要重写！Kotlin 和 Java 可以完美的在一起工作。你可以在 Kotlin 中很自然的调用 Java，反之亦然。 就如 Objective C 和 Swift 之间不需要 interop 或者类似中间者。所以你可以在每一个类中决定哪一种语言你工作起来更好。
一门新的语言会拖慢我们
Uncle Bob 前段时间这样写道：每一种新的语言都将我们甩在时间后面，因为我们的工具链需要从0开发。看看 Swift，即使到今天，XCode中对 Swift 的支持还达不到之前对 Objective C 的友好程度。Kotlin 的伟大之处在于它来自工具厂商。它来自给我们开发 IntelliJ（Android Studio 的基础） 的那群家伙。IntelliJ 中对 Kotlin 的支持和对 Java 的支持友好度是一样的。原因就是工具支持。Groovy，一门现代语言，尽管已经出现了很多年，从未获得过 Kotlin 现在所获得的支持。
此外你所有的处理字节码的检查工具也是开箱即用。剩下的可能就是处理源码的静态检查工具。这是一小步的后退，但是很快就会解决。与此同时我们有 Klint作为备选保证我们发布高质量的代码。
所以为什么我们的权益相关者会犹豫？
因为大多数公司移动端已经成为核心业务。不管你在哪一个领域，你的大多数客户都是通过 app 找到你。但是在你的核心业务上，你需要谨慎对待变化，这是完全合乎逻辑的。
变化，移动应用的本质
但是，也请我们记住：移动应用开发时通过持续变化定义的。与后端开发世界不同，事物在持续不断快速变化。
在 Android 出现的这些年里，我们至少经历了3种完全不同的用户交互体系：Pre Holo, Holo 和 Material Design。我们有3种不同的推送通知的 API：XXX，GCM 和 Firebase。 仅仅在几年前广受传播的应用架构还是使用 Content Provider 来封装 HTTP 请求。你的 REST 客户端（也许是基于 Apache）需要将结果写入到 SQLite 数据库。仅仅在几年前依赖注入还因为性能原因作为反模式对待。没有 ReactiveX，函数式编程仅仅停留在后端开发或者大学校园里。
我们移动开发者如果学会了一件事情：变化是持续的。你写下他们的这一刻他们可能已经过时了。一个3年内都没有去碰的应用可以扔掉了。这在 Android 上是有效的，未来也是这样。尝试去寻找一位愿意开发还支持 Android 2 的应用的开发者，或者愿意使用前面提到的 Content Provider 模式的开发者！祝你好运。
不要落后
Kotlin 仅仅只这些变化中的另外一个。不要错过这个机会。谁知道你现在保护的 Java 代码库会不会成为我们所说的遗产系统。
本文译自 Kotlin in Production: Should you stay or should you go?
获得原文作者授权
