半年前我在一个两年历史的后端 Java 项目中，尝试着引入了 Kotlin，半年过去，证明了当时的尝试是值得的。分享一下我的感受。

优点

无缝引入到现有 Java 项目，只看了半天文档就上手了，并且没有因为两种语言混合开发带来副作用。
表达能力优于 Java，平均下来，在不影响可读性的情况下，大概可以比 Java 少写 1/3 的代码。
增加特性的同时，没有降低性能，部分 benchmark 中还有微弱的性能提升，马儿跑得更快还吃的更少。
适度的函数式编程支持，map-filter-fold 代替了一大堆 for-loop，简洁明了，代码中没有 map/list 构造工作干扰视线。
extension function 可以很方便的给现有的类扩充新的方法，而不用定义新类型，最常用的就是 TypeA.toTypeB()。
non-null 变量和 elvis 操作符，基本上消灭了 null 的烦恼，既不担心 NPE，又不用到处 if 判断是不是 null。
unchecked exception，可以自己决定在调用栈的某一层 catch 和处理，不必到处 try-catch 好麻烦。
val 和 var，在变量定义时决定它是否可以改变它的值，不能改变的值，是不用担心不小心覆盖的。
property 语法，不用让 IDE 自动生成 getter/setter 了，也不用 Lombok 自动合成这些方法了。
object，匿名对象信手拈来，并且编译器自动帮你搞成线程安全的 singleton。
delegate，和用它实现的 lazy evaluation，你甚至可以自行决定 lazy 求值在并发时的同步方式。
String Interpolation，"aaa$x"或者"aaa${x.y}"是不是很面熟？多行字符串也很方便。
when/let/apply/also/takeIf 等等操作，可以实现非常简洁的操控，直接消除掉 builder 设计模式了。
imutable 的 list/set/map，imutable 是个很好的约束工具，默认就该 imutable。
REPL，就是类似 jshell 的那个东西，很方便，也很实用，比如直接命令行访问某个类。

缺点

$符号用于 String Interpolation，当前版本的 IDEA 无法正确处理 Value 注解中转义过的$。
spring-data 中 query builder 依赖的机制，目前不能方便的自动生成 Kotlin 的 Query Object。
资料还是偏少，不过官网的文档差不多也够了，毕竟大部分库和框架，都是沿用的 Java 的。
IDEA 自动转换工具，把 Java 转换成 Kotlin，转换质量明显比我人肉转的要差的多。

目前项目中一共有 200 多个 Java/Kotlin 代码文件，2/3 已经是 Kotlin 的了，估计半年后 Kotlin only 了。下半年准备尝试用 coroutine 改造一下现有的多线程架构，3000 个线程已经限制到某些产品上的玩法了，异步回调的话又不太适合调用栈很深并且各种分支和跳转的业务，kotlin 的协程，可以直接 wrap 现有的异步的库，设计思路上很赞，充分利用现有的库。

kotlinjs 虽然正式发布了，但是 runtime 太大，而且我已经用 coffeescript 了，就没有尝试。

kotlin native 目前继续观望，也许明年会在合适的地方尝试一下，这也是个比较有趣的东西。

notreami

2017-07-08 15:21:33 +08:00

@sagaxu 除了简洁，不觉得语法上限制会导致特性上的限制，而且完全可以造一段语法出来，比如注解、lambda。Kotlin 体系不完整指的是需要依赖 java 提供生态，而不是像 Scala 一样，完全可以自成生态（可以预想，以后 android 的开源库应该大部分都是纯 java 写）。
go 或者 js 我提的是掌握，不只是它们的语法，还包括它们的生态库。这样拿来和 Kotlin 对比才有价值。

把 Kotlin 引入除了语法糖，一直觉得没有什么意义。甚至还不如好好把 gradle 掌握了更有意义。

未免不必要的麻烦。综上，我想表达是，需要掌握的技能栈很多，一门技能栈好上加好的价值大还是横向扩展技能栈的价值大。毕竟人的时间有限，除非你很聪明，比我学习和掌握一门技术所花时间短很多，那就当我没说过，毕竟你时间多。

sagaxu

2017-07-08 16:57:32 +08:00

@notreami 注解只能缓解，不能根治语法的不足，比如做 DSL 的时候，用 Java 就很麻烦，用 Kotlin 或者 ruby 就很简单。

像这样一段 DSL，你用 Java 和注解可以很简单的实现吗？

html {
head {
title { +"XML encoding with Kotlin" }
}
body {
h1 { +"XML encoding with Kotlin" }
p { +"this format is now type-safe" }

/* an element with attributes and text content */
a(href="http://jetbrains.com/kotlin") { +"Kotlin" }
}
}

gradle 之所以用 groovy 做 build 的 DSL，也是因为语法表达灵活，现在 gradle 也支持 Kotlin 的 DSL 了，写法跟 groovy 的基本一致。

Kotlin 不自己造轮子，充分利用 Java 的库，这正是它最聪明的地方，因为数据结构都是 Java 的，跟 Java 才没有 interop 的麻烦，Kotlin 调用 Java 或者 Java 调用 Kotlin，不用做数据结构的转换，也不用任何 wrap，就跟调用自己语言写的库一样方便。一段 JVM 字节码，是 Java 编译来的，还是 Kotlin 编译来的，没什么明显差异，所以原生不原生也无从谈起了。

在技术的路线上，是深度更有价值还是广度更有价值，因人而异，同一个人的不同阶段答案也不同。

sagaxu

2017-07-09 12:01:31 +08:00

@wohenyingyu02 Kotlin 在 JVM 调 C 库等同于 Java，Kotlin Native 只能调 C 库不能调 Java 库。

@succlz123 JVM 字节码混淆工具，理论上不应该区分 Java 和 Kotlin 生成的字节码。

@Miy4mori null safe 跟 Java 交互，调用 Java 的时候可以保证不会传不该 null 的 null 给 Java，获取 Java 返回值的时候可以写个!!后缀假定它是 nonnull 的，也可以假定它是可以 null 的，并不会损失 null safety。
能写的舒服一点，读的舒服一点，顺带稍微减少点 bug，已经足够了。

Kotlin 协程不知道算不算解决的实质问题，如果不用协程，我们新的需求要把 3000 个线程变成 30000 个，而用 akka 或者 vertx 这样的库又很难处理复杂业务逻辑，每次请求都要调用几十个服务，状态个数都超过 100 个了。如果不是有 Kotlin 协程，都计划用 Go 语言重写，放弃 JVM 了。

darkread

2018-01-04 14:44:06 +08:00

@notreami 我觉得你这个说法很奇怪。你 golang 可以用 java 库么？你的 js 可以用 java 库么？都不行。你说转 golang，那你转吧，Go 是很火，你想清楚要造多少轮子，再说，有没有是一回事，好不好是另外一回事。java 有 Spring，Go 有 GoBee，但是事实上，GoBee 有很多问题。你愿意一个个去尝试，就去吧，不要误导别人啊。
kotlin 可以啊，我有简便的 null 检查，不需要写丑陋的 helpler，为什么不用？我 lambda 是一类公民为什么不用？
说对了，就是爽！就是代码少！你等 java9 来了，你用么？ Java9 有 kotlin 好用么？
等 Oracle 收购？你做梦吧，kotlin 是 gg 宣布支持的第三个 Android 顶级语言，为什么不就是为了对抗 Oracle 向 GG 收取 java 收取费么？会把对抗武器卖给敌人？

Kotlin 入坑半年总结

优点

缺点