谷歌在今日举行的 I/O 大会上宣布，Kotlin 编程语言现在是 Android 应用程序开发人员的首选语言。
image from: techcrunch.com
Kotlin 由 JetBrains 公司开发，与 Java 100% 互通，并具备诸多 Java 不支持的特性。两年前的 I/O 2017 年上，谷歌才宣布在其 Android Studio IDE 中支持 Kotlin，Kotlin 与 Java 并存，开始成为 Android 开发的一级语言，当时业界并不太看好，因为 Java 在安卓的发展过程中做出了巨大的贡献，其作为 Android 开发语言不二之选的观念已经根深蒂固，而且它也一直在不断完善。
然而仅仅几年时间，Kotlin 因其相比 Java 更安全与简洁等优越性，很快占领市场，谷歌 Android 首席布道师 Chet Haase 表示：“在过去的两年中，Kotlin 受欢迎程度一直在提高，超过 50％ 的专业 Android 开发人员现在使用 Kotlin 开发他们的应用”。从今年 Stack Overflow 年度开发者调查的数据中也能看到这一点，如下图所示，报告中指出，在开发者最喜爱的编程语言中，Kotlin 得到了 72.6% 正面反馈。
“我们宣布，我们正在采取的下一个重大步骤是 Kotlin-first，Android 开发将越来越多地以 Kotlin 为主”，Chet 表示：“许多新的 Jetpack API 和功能将首先在 Kotlin 中提供。如果你要开始一个新项目，你应该使用 Kotlin 编写，用 Kotlin 可以大量减少代码量，同时也减轻了测试和维护的负担。”
作为 Android 开发者的你，从 Java 转到 Kotlin 了没？
消息来源：Tech Crunch
我是17年开始使用kotlin的，当时唯一存在的问题是，我开发的Android，可是身边会kotlin的并不多，维护旧代码成为问题，于是技术经理要求改回Java……
从java->kotlin再kotlin->java已经过去一年多，现在的情况是太久没写kotlin，kotlin能看懂，但是已经不会写了……
引用来自“monkz”的评论
如果用kotlin，还不如直接用flutter。引用来自“longforus”的评论
请问一个语言一个框架有什么必然的联系吗?flutter用的也是dart好吧,和kotlin有什么关系?引用来自“monkz”的评论
我意思是换kotlin开发安卓，不如用flutter开发app，是谷歌主推的app开发。引用来自“monkz”的评论
如果用kotlin，还不如直接用flutter。引用来自“longforus”的评论
请问一个语言一个框架有什么必然的联系吗?flutter用的也是dart好吧,和kotlin有什么关系?引用来自“monkz”的评论
如果用kotlin，还不如直接用flutter。引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“行走在赤道”的评论
2B团队嘛。楼主看来是高级黑啊。要不然怎么会说了一大堆却没有提供任何客观依据？本人所在公司使用 kotlin 服务端已经超过 2 年，到目前为止没有遇到过任何与 java 兼容性的问题。#DuiC#
引用来自“catalogMan”的评论
奇奇怪怪的rpc序列化问题，痛苦的springboot配置兼容性问题，类型推断导致后期维护可读性降低问题，等等。我到不是黑它，就像我说的，有他不擅长的场景，比如分布式多服务项目，特别是已有业务已经用Java那一套跑在线上的情况引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“xiaolei123”的评论
无知引用来自“holysky”的评论
@xiaolei123 无知+1引用来自“catalogMan”的评论
我可是参与了一个项目开发到上线，现在做了反思，你说我无知？？引用来自“嘉树”的评论
我觉得你说的倒是挺诚恳了，代码可读性很重要啊自家有dart、go不用，非要用第三方的，在技术上谷歌就是喜欢走捷径，怎么省钱怎么来，地地道道的商人，kotlin-first不是因为kotlin优秀，而是看ide周边都省事了
引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“xiaolei123”的评论
无知引用来自“holysky”的评论
@xiaolei123 无知+1引用来自“catalogMan”的评论
我可是参与了一个项目开发到上线，现在做了反思，你说我无知？？引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“xiaolei123”的评论
技术经理表示kotlin不稳定 不予采用引用来自“乌扎拉”的评论
再过两年谷歌宣布安卓不再支持Java，就傻眼了。引用来自“陈钇蒙”的评论
过两年应该推fushia代替安卓了引用来自“乌扎拉”的评论
fushia还会用java吗？引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“xiaolei123”的评论
技术经理表示kotlin不稳定 不予采用引用来自“乌扎拉”的评论
再过两年谷歌宣布安卓不再支持Java，就傻眼了。引用来自“陈钇蒙”的评论
过两年应该推fushia代替安卓了引用来自“先进哥”的评论
然后推出一批只有kotlin才能调用的库，然后java库退役引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“行走在赤道”的评论
2B团队嘛。楼主看来是高级黑啊。要不然怎么会说了一大堆却没有提供任何客观依据？本人所在公司使用 kotlin 服务端已经超过 2 年，到目前为止没有遇到过任何与 java 兼容性的问题。#DuiC#
引用来自“catalogMan”的评论
奇奇怪怪的rpc序列化问题，痛苦的springboot配置兼容性问题，类型推断导致后期维护可读性降低问题，等等。我到不是黑它，就像我说的，有他不擅长的场景，比如分布式多服务项目，特别是已有业务已经用Java那一套跑在线上的情况类型推断，你觉得降低了可读性，这实在没什么好讲的，因为 java 也支持了这个功能了，而且新生语言 go rust 哪个不支持类型推断？？？
引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“xiaolei123”的评论
无知引用来自“holysky”的评论
@xiaolei123 无知+1引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“行走在赤道”的评论
2B团队嘛。楼主看来是高级黑啊。要不然怎么会说了一大堆却没有提供任何客观依据？本人所在公司使用 kotlin 服务端已经超过 2 年，到目前为止没有遇到过任何与 java 兼容性的问题。#DuiC#
引用来自“塔塔米”的评论
被驴一般的赶向kontlin引用来自“keep_wan”的评论
哥们你字都打错了.引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。本人所在公司使用 kotlin 服务端已经超过 2 年，到目前为止没有遇到过任何与 java 兼容性的问题。#DuiC#
引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“catalogMan”的评论
2B团队，曾经尝试迁移到 Kotlin 一年时间，后来不得不再迁回 Java8，诚然 Kotlin 写起来非常有意思，但是带来的是团队协作层面的可读性降低，再加上与市场上各种 Java 库奇奇怪怪的兼容问题（虽然号称无缝兼容，但只是号称）。尝试一年后再看回 Java 啰啰嗦嗦的代码居然格外清切，不用费脑子就能看懂，不用到处去找各种语法糖、扩展是在哪里声明的。这一点就像 Golang 说的 『Keep simple，Keep stupid』，只能说每种语言都有不擅长的场景。引用来自“xiaolei123”的评论
无知引用来自“xiaolei123”的评论
技术经理表示kotlin不稳定 不予采用引用来自“乌扎拉”的评论
再过两年谷歌宣布安卓不再支持Java，就傻眼了。引用来自“xiaolei123”的评论
技术经理表示kotlin不稳定 不予采用引用来自“山雨欲来”的评论
谷 果然牛逼，说发明一门语言就发明一门语言 而且还牛逼哄哄java程序员们...
引用来自“Lyon1994”的评论
如果flutter支持用kotlin开发就更完美了，不用再去学dart可😂引用来自“塔塔米”的评论
被驴一般的赶向kontlin引用来自“CielSwift”的评论
这还是一个运行在jvm上的语言，还能调用Java中库，这就是个