Kotlin 目前有个很明显的优点，就是实现了协程（用户态线程），可以减少资源的开销

以前到处用 kotlin ，现在能用 ts 就用 ts ，kotlin 几乎没有什么缺点但是背靠 gradle ，进入前端领域后我是越来越不能接受 gradle 了。

肯定有，但是不多90%以上的业务系统不在乎那点性能，而且更在乎换语言之后的风险和成本提高

尝试过

你这过时了，JDK 21 就实现了所谓的协程，这个有点对于现在的 Java 而言不算什么；不过，万恶的 NPE 处理确实还是痛点，虽然有 Optional 来规避问题。

Kotlin 不是和兼容 java 吗

大部分还是 JDK8 🤣

怎么可能，我们早就是 JDK 17 了

可以先试试新增一个 src/main/kotlin 直接写

我们。目的是为了 Safe Call 和 val

＃7 确实很多项目还是 jdk8

这语言挺好用的呀。我们用了好多年了，上线了好几个后端项目了。没遇到啥语言上的问题。这语言对比其他 JVM 语言，变化算少的了。如果不用一些复杂的语法，纯粹可以当做简化版的 Java 用。特别是 val 变量声明，用了这个，几乎杜绝了我们项目里所有 NPE 问题。协程的话，没有 go 和 C＃的好用，但也帮助我们解决了某些特殊需求。

＃7 现实就是公司内 90% 的项目还是使用 JDK 8 ，压根就没有办法升级，一定要升级的话，内部自研的中间件就得全部跟着一起升，以此来完成框架适配跟特性兼容，风险跟成本都很大

虽然和 java 兼容,但是协作的时候强制同事学习 Kotlin 不太友好,而且领导也不会同意你随意变更技术栈,个人项目或者小团队协商好倒是可以上

我们公司大规模的都是 kotlin+springboot 的模式，很少 java+springboot ，写了这么久的 kotlin ，感觉 kotlin 并没有比 java 好多少。。。。，都是业务语言而已，只是一些非空判断？，优点用，其他的感觉没啥大的区别，语法糖没有那么重要。

用 但是没用协程用 reactive 的框架才能用上协程，比如 vertx ktorspring 底层就写死了 thread per request

不同意。Kotlin 远比 Java 复杂，和“精简版 Java”八竿子打不着。只能说你用的是简化版的 Kotlin 。

在升级 Java 21 （从 11 升），老代码基本没咋动

没有 NPE 是因为语言/编译器层面实现的 null safety ，不是因为 val （ immutability ）。

有StubHub 被卖掉之前很多新的后端都是用 Kotlin+SpringBoot+WebFlux 写的 ＃1 并不强绑定 gradle 啊，我们当时就是用 maven 构建

java 21 实现的不叫协程（ coroutine ）。现在好像叫虚拟线程（ virtual thread ）的比较多。也有别的叫法，但是不能叫做“协程”。协程的“协”一般要求使用者明确定义把当前线程的使用权交给其它协程的时机（ suspend ）。

用了四年了, 我感觉 kotlin 的优点是语法糖和 null 安全

我公司 java 都全部转移 kotlin 了。就光是解决了 NPE ，就已经是无敌的理由了

Kotlin 和 Scala 都有，主要是解决 NPE 问题，都跑在 JVM 上所以性能无差。至于说感受不出区别的，大概是项目太小或者没有深入使用语言特性吧。

嗯，我记错了。有一段时间没写后端了。我们团队里面，各种原因，kotlin 的特性也没有用的很深。只是觉得写起来比较简短和自由。当然，kotlin 的一大缺点就是编译时间太长了。

公司项目是用 Java 和 Kotlin 混用写，Kotlin 看起来是比较简洁，但也算不上什么，null safety 的机制确实不错，但 Kotlin 本身在新人学习成本和真正的程序性能考量上感觉帮助不大。

kotlin 和 java 的现状就犹如 gradle 和 maven 。发展这么多年也说实话估计也就这样的，有优势，但是没有替换必要。当然总是付出沉默成本的人不愿接受现实来说 kotlin 的好话。

kotlin 的协程在后端领域全是 Spring 全家桶的情况下，只要不换 webflux ，协程就一点用处没有，完全用不起来我现在自己的小项目用 kotlin+springboot 写的，想用协程也没办法，最后想要执行快还是暴力堆了线程加 Future 来实现

公司老项目我都改了 Java+Kotlin ，直接把代码生成器改成生成 Kotlin ，新项目直接全 Kotlin ，爽飞了~

只聊性能纵向不如 GraalVM+JDK17 横向不如 go 整体都不如直接上手搞点架构，做点 infra等死吧别指望 Kotlin 了

写过玩具，没有上过生产用过

在公司的一个小模块尝试过，用来实现 DSL ，感觉还不错

＃4 虚拟线程 VT 不是协程，这是两回事

kotlin 主要是写的爽，开发效率高，不容易写出错误。性能和 Java 是一样的，而且协程的优势快被虚拟线程抹平了，此外协程也没有解决阻塞 IO 的问题，相反虚拟线程是真的解决了 IO 问题的

go 的是啥

JVM 语言，只要一个 JAVA 就够了。学 kotlin 不如去学学 go,rust,ts,python 这些中的若干个。 安卓的可以尝试下 kotlin ，scala 不是写 spark 的没必要学，当然，我猜一定有人用 Play Framework

有啊,很多啊.我做安卓和后端全是 kotlin

最近一个后端项目：ktor + kotlinx + flow api + coroutine + context receivers + arrow.ktJDK 21 开 Generational ZGC 和 Virtual Thread （作为 coroutine 的 blocking dispatcher ）我算啥成分？

我是精通 Scala ，同时也熟悉且写过万把行 Rust ，所以换到 Kotlin 对我来说算是能力上封印了。至于论坛里没写过几行 coroutine 的开发来说，对鞋城和虚拟县城的理解不一定强于前端仔（ async/await ），现在谈 VT 取代 coroutine 有点言之过早

＃1 gradle 有什么问题吗？

gradle 咋说也比 node 好吧

很少很少 Java 后端 Java 必学 Kotlin 也就 Andorid 用的多

go 的叫 goroutine ，和 Java 虚拟线程是一类东西。

如果没有虚拟线程，也许过几年会有些人陆陆续续接触一点协程。但是有了虚拟线程之后大部分人不可能去尝试协程了。说“取代”不准确，也许应该叫“抑制”。

注意部分库的问题，如果大部分只需要覆盖 curd ，那肯定 kotlin 爽啊。

• 太重了。五六年前的笔记本运行巫师 3 还能经常保持 60 帧，gradle 编译大点的项目会把电脑卡成 ppt 。- 太慢了。第一次执行任务很慢，同步/编译脚本很慢，下载依赖很慢。- 命令行使用几乎没有开发体验。node 有什么命令看一眼 package.json 一目了然； gradle 的任务，只能说还好有 idea 。- 太过灵活太过复杂，而且 api 变动得太频繁。特别是 android 相关的，几年时间里，官方模板里的 build.gradle settings.gradle 不知道变了多少次。groovy -> kts ，buildSrc, libs.versions.toml, compile -> api, implementation 这类变动实在是太多了。虽然是不同的技术栈，很多问题 jvm 可能要背首锅，但是类比 js 生态中的 bun/vite/npmp 和 node/webpack/npm ，gradle 能做得更好，但是从 4.x 用到 8.x 感觉 gradle 还是同样的 gradle 。

android 出身还从没用过 maven ，请问 maven 相比 gradle 有哪些优势？只知道 maven 有个 xml 配置文件好像更简单直观点，不过现在我个人的 kotlin 项目主要是 kmp 相关的，暂时也用不上 maven 了。

一直都是 kotlin + maven 做后端，效率非常高

＃46 我没深入用过 gradle 就不评判了maven 给我的感觉跟你一样，就是简洁直观再就是历史惯性，后端一直习惯用 maven 就懒得再换

从 java 上手快，减少空指针，语法比 java 好很多，开发速度比 java 快，有时候自己写一写代码会用。我是老板我会推的

我们组已经完成了全部 java 转 kotlin ，其实也花不了多久大部分 idea 都给自动化了