这波 jdk21 的更新，会不会引发 go 系统重构成 Java 的 kpi 需求

为啥会用 java 做 native 开发？这需求就很怪。。。完全不符合 java 的定位啊

@liprais #16
在 5 小时内，在一个 40 多个回复的，讨论 JDK 在线程方面的更新是否可能与 Go 产生竞争的帖子中，有且仅有一个回复技术性地讨论了.NET 在异步方面的优点与不足。被 @liprais 概括为.NET 神教闻着 JAVA 的味就来了，确实很能体现 @liprais 的优秀素质与高超的 JAVA 编程水平。

@idealhs 你是第二个上钩的，直钩都咬还说不是.net 神教，咋地传教还打狼来一群才叫传教啊

@assiadamo 我弄个小服务给别人跑，凭什么上来要我装一坨 jre ，有两年 jre 下载还特别难找要注册账号之类。 看看 JB 家的 IDE 那是个个自带 jre ，不同的 jre 和不同平台的 jre 也并不是真的完全一样能互相兼容。
我就希望体积小一点，然后 30mb 内存搞定。java 再小的程序带上 jre 压缩完都差不多 50mb 开外，一上来就吃大概 200mb 内存。

一次编译是真的，运行是哪儿都运行不了

@guilinxiaobing 唯一一个？井底之蛙胡说八道啥呢

@coer 当年.NET 引入 async/await 的时候 ,底层库都加入了 async 重载

你想多了，最少还得过 5 年，才有可能会有 go 改 java 。

另外说一句， 就算 java 有了这些其他语言早就有的，graalvm 不成熟稳定吧，java 打包二进制体积，启动速度提升依然都还早。新技术要求语言的新功能和特性，java 一个都没有。这几年业界关注的
都是语言有库集成 ebpf, 语言整合 wasm 配合 wasi 运行时。

用 go 来写业务的，有可能也有价值转 java21 ，其他的没啥转的意义。go 用来写业务怪怪的，开发效率不如 java

virtual thread 又不是 coroutine 。

锁神教的教徒们还是会继续上锁，然后把 carrier 干废。

重构吧……恭喜你重新发明了响应式编程。

拿头跟原生支持异步模型的语言比。

说 java8 升级到 java21 的，应该主要是针对老项目吧？

老项目的维护，一般企业都会选择维持版本吧，好端端的屎山能跑就行，升级之后还可能出现更多问题。但是鼓励开发者在新项目上尝试新 jdk 是很有必要的。我就是有老项目 java8 ，新项目 java17 ，前年和去年也有项目是 java11 的。

我为什么写 go ，简单啊。当年就觉得 java 写代码太啰嗦了。

两者的业务思路逐渐区分开来了

go 主要是写中间件，基础设施，主战场在云原生那里，最典型的应用就是 docker 了。

Java 因为其啰嗦的静态语言特性，适合写大型业务系统，主战场在业务那里，兼顾开发效率和性能，而且需求量不是 go 能比的。。业务系统拖一个 200MB 的 JDK 完全小 case 。。但一个中间件/基础设施的包就要拖一个 jdk 的确是蛋疼，这也是 go 的天然优势。

用哪个还是看自己主打方向。

業務地盤都保不住了， 別想著動 GO 的樂，VT 本就是為了兼容舊代碼而妥協的產物，性能連 reactive 都比不上。

对我来说 java 最大的问题是内存.go 启动一下 10m 占用. java 启动 2G 算轻量.