旧闻: Vert.x 5 发布

一个月前我就升级了几个项目，从 3.X 使用至今，这个项目总体非常好，就是小版本更新改动有点大，我就遇到过 10 来次小版本更新出大 bug 导致系统无法使用的情况，不过官方修复速度很快，一般几天内就解决了。

quarkus 就是基于 vertx 开发的，易用性对标 springboot 。使用上唯一缺点就是 promise/future 没写熟练前太绕了，vertx 项目组之前试过几种 agent 方案，都不理想。后来有了 Kotlin coroutine 之后，难写难理解的问题就根治了。如果不想用 Kotlin ，Java 24 之后可以用 Virtual Threads ，也能跟 vertx 集成，尽管可能偶尔还有点儿小问题。

性能是非常好，但大部分场景用不上，且中文资料少，招人太难，大规模使用不起来。尤其是有了 Virtual Threads 之后，springboot 也能支持一些高并发网关型场景了，更没必要学了。

我们组就在用
这东西太看写的人的水平了

之前用过，写得好的话性能确实不错，写的烂那还不如用 Spring 。

然后写一段时间你就发现，你真的有那么多客户，且又舍不得开机器，值得让自己写这拧巴玩意吗？
后来就改回 Spring 了，反正那么俩并发也不差几个 CPU 钱。

这东西写点简单逻辑还行，项目大，人多以后就很难控制每个人的水平，进而导致你要花大量维护 Review 培训的成本才能保证项目不烂掉。

机器成本能看得到，但人力成本很多时候比机器更大。花掉那么多人力成本就为了省那么俩 CPU 真的值得吗？

@Mithril 我觉得是内存成本，不是 CPU ，成本。

virtual threads 发布了，vertx 的优势不大了吧。

我司就在用，还好新项目不用了

这个服务器成本换开发成本，亏爆了

弯弯绕绕太多了，还真不如 go 一把梭😂

以前我觉得这是好东西，现在看生态位太尴尬了。

如果让一个 java 团队都达到能掌握这套框架的程度，付出的成本还真不如让他们直接学 go 。

而且微服务部分跟 spring-cloud 一样尴尬，里面绝大部分的东西，5202 的今天大部分已经不需要在应用开发框架上解决，基础设施已经覆盖掉大部分功能。

vert.x 确实是好东西，但会用这玩意的大概率也会试着逃离 Java 换技术栈了。不会用的，吹再好他们也不会用。

vertx 的门槛在于不愿学而不是学不会
如果 spring 的源码是坨粑粑，那 vertx 的算是巧克力了，没有 ioc/aop 非常的舒适
vt 和 vertx 关系也不大，因为 vertx 的场景就是非阻塞，阻塞用 vertx 就是没事找罪受