Java 玩腻了 其实发现 golang 也还不错 确实很简洁

[silentsky]

[vincent7245]

golang 没意思，在玩 rust

[Subfire]

@chaleaochexist Project Loom

[magicZ]

一个月前，我发了一个帖子 https://www.v2ex.com/t/1002653#reply12 ，
根据里面的回答看以及周志明老师的文章看 （ https://jingyecn.top:18080/tricks/2020/java-crisis/qcon.html ），
Project Leyden,Project Valhalla 还没有突破，但可喜的是 Project Loom 再 21 版本提供了虚拟线程。
java 目前是存在危机的, 腾讯新闻放弃 PHP 转投 Go ，10 万行代码重构（ https://zhuanlan.zhihu.com/p/675879401 ）。
对于一门发展了 25 年的长青语言，希望它发展的更好。

[veightz]

@yooomu 1.18+的话，处理集合可以试试 https://github.com/samber/lo

[lesismal]

@beneo 跟站长要了封禁，解封后才来回复。如果是自己的代码，自己的日志带文件行号就可以了。如果是三方库，这个没办法直接获取三方 error 堆栈，如果不是本地开发环境只能根据 error 去源码里搜之类的，如果是开发期间 debug 可以调试进去看。
通常库里不应该抛出异常，因为如果业务层没有 recover 这会导致业务宕机。
致于 error 堆栈，库自己多 wrap 上堆栈信息的话会性能下降，而且 golang error 也是历史原因了，我前阵子也在琢磨，要不要把自己库里加个配置项、允许用户设置 error wrapper ，然后库里返回的地方都用用户的 wrapper 包装后再返回，这样如果用户想要堆栈、可以自己设置 error wrapper 。但这个改动的工作量也挺大的，而且即使默认只是空的 error wrapper 也会略影响性能，所以我还是倾向于不加这个，尽量保障框架自己稳定、不给用户添麻烦或者不需要用户那么麻烦必须深入到框架内不才能解决。

golang 的 orm 没有好用的，如果有兴趣，欢迎试试我的 rawsql 方案：
https://github.com/lesismal/sqlw

[lesismal]

@diagnostics 淡定下来，咱们不搞语言之争了，各自能解决业务问题就行。

> 天天秒天秒地，就拿 gRPC 来说，Java 的差距很大吗？ https://github.com/LesnyRumcajs/grpc_bench/wiki/2022-04-23-bench-results

gRPC 本来我也是不支持的，所以我用我自己的 arpc ，易用性、可以支持的业务类型比 gRPC 丰富的多，至于性能，因为 gRPC 非要 HTTP2.0 ，但绝大多数 RPC 都是内网服务之间的调用，所以相比于直接 TCP 的框架，gRPC 性能是比较差的，这里有三方鸟窝老师的对比，可以看下我的 arpc 的数据，还可以，但是当然，go 实现的怎么也干不过 c/cpp/rust 这些的性能，我自己如果写 c/cpp 的版本肯定也能随便灭 go 版本的性能：
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/

> 我自己写 Java 也写 Scala ，只不过混了个开源基金会的 Committer

只要能被合并，至少都是符合了大项目很多规范的，所以 Committer 挺不错的。但抛开规范之外的技术含量本身，还是要看实际 PR 内容的技术难度，所以也没太大必要拿 Committer 说事，我其他号也给 apache PR 过也合并过的，但不是特别重要的内容，所以我对 apache 贡献也几乎可以忽略。身边也有其他项目的 Commiter 比如 Netty 的，但也是非核心功能

> 不敢不敢，我没能力，说出来的话，感觉丢其他的脸，拿这个东西来比。

这个确实没必要，尤其我那个个人小项目，主要都是自己写、图自己方便，项目规范也没搞那么多，连注释文档我都没空好好整理详细，主要精力优先放在保证功能良好稳定和各种兼容上了、尽量让用户用着舒服

> 哥们，求求你了，去把 Flink 重写，中国开源第一人应该就是你了。你知道大数据用多少台机器，都跑在 JVM 下吗？我记得前几年阿里宣传 Fink 的案例好像都是千台服务，你用 Go 重写应该能降到 500 台以下吧？别的不说，达摩院院长你来当

平常心平常心，咱别说气话。
讲真，术业有专攻，大数据基础设施我目前只是用户，没有自己造过。而且大项目耗时费力的，个人用爱发电不划算。但如果兄台有认识的团队想试试搞这些项目优化 java 版本的开销和性能，可以来找我，价钱给到位，个人水平有限不是一定能搞定，但还是可以搞搞试试看的

[lesismal]

> 脱离你的业务场景去谈我要用什么语言是很无聊的， 除非你是架构师，架构你说算了，或你是技术总监， 技术路线你说了算

啊这样子啊，那好像没毛病，我们团队技术是我说了算的，而且我确实把旧的 java 项目都用 go 重构了，没了 java 以后，开发和运维大家都很开心，软硬件成本也降了、老板也开心 🤗

[beneo]

@lesismal 所以 go 就是 一个大公司全部自己搞，然后鼓吹 go 多好多好；不能拿着 Java 的生态去憧憬 go 有多好的资源，因为一不小心就是大坑，还救不回来

[lesismal]

@wanqiangcrack #167 忘记 at 了

> 脱离你的业务场景去谈我要用什么语言是很无聊的， 除非你是架构师，架构你说算了，或你是技术总监， 技术路线你说了算

啊这样子啊，那好像没毛病，我们团队技术是我说了算的，而且我确实把旧的 java 项目都用 go 重构了，没了 java 以后，开发和运维大家都很开心，软硬件成本也降了、老板也开心 🤗

[lesismal]

@beneo
也不算吧，小公司一样搞啊，别用什么奇葩姿势、别用那些对工程不友好的库（例如 orm 相关的）就可以呀。

关键是很多人，他们本来熟悉了 java 那套，然后刚刚转到 go 没多久，还非要按照 java 的习惯去找 go 对应的轮子，go 没有就说 go 不行，这是开箱使用姿势不对啊：因为本质上你是做业务实现需求，本质上你应该寻找 go 的能实现需求的轮子，而不是非要找 go 生态里的像 java 的轮子。

抛开基础设施领域的 A 有 B 没有，对于业务而言，http 足够好用的框架大家都有，堆栈你如果用 gin 、echo 那些加上中间件就可以，logger 挑个三方成熟的就可以，标准库 sql 你写 raw sql 也没问题，但是非要找 go 的 orm 去用然后说 go 不行，这。。。

还有一类其他语言转 go 的，例如 javaer 、phper 转 go 然后搞一套类似 java 、php 的框架，虽然臃肿了点我个人比较抵触，但是对于原本的 javaer 、phper 确实也方便一点。但是他们的框架可能也依赖了 golang 的一些不好的库比如 orm ，但也不是必须使用它才行，也可以自己 raw sql 的。而且不管怎么说，这些框架它不是 go 本身，也不能因为它不行就说 go 不行吧。毕竟标准库、gin 、echo 也都足够用

基础姿势没搞明白，然后去使用不好的方案，然后说 go 不行。对不起，这个锅 go 不背

如果都是初学者，不带着 java 、php 的经验和偏见来学 go 的 gopher ，我还没见过几个喷 go 的，反倒都说 go 容易上手、也不需要依赖太多轮子就能把项目搞得很好

[lesismal]

@beneo 类似的 go java 好坏的我就不再聊了，免得又浪费时间了。。

[diagnostics]

@lesismal #166 也可以继续讨论下去，只要别嘴炮，光说问题不说原因，当个键盘侠。

以朴素点的语言来说，也不针锋相对，你说 Java 语言性能不如 Go ，我先以你的视角帮你举例：

从编译实现角度上，Java 非 AOT 编译，而是编译为字节码，需要解释器来解释成机器码，注定其性能较低。

> 我的回答：Java 最初的目的是为了实现一次编译多次运行，因此在机器码和源代码之前增加了额外的字节码，由解释器来运行，其初始性能确实低于其他 AOT 的语言，不只是 GO ，但相对的 Trade Off 就是，牺牲了初始执行效率，换来了一次编译，不同平台运行；也换来了编译速度的提升。对于操作系统级别的优化（如 IO 实现等）由 JVM 来实现，对于后续的代码执行效率，由 C1 、C2 等 JIT 优化为性能更好机器码；而且 JIT 相对 AOT ，更匹配生产（现实）环境的代码热点（不同流量下的结果可能不同）

再从编译器对代码的性能优化来举例，例如你可以举例 GO 有，但是 Java 没有，或者某个编译优化技术在 Java 里实现的非常差的，可以尽管举例（例如代码修剪类的 inline ）

JDK 相关的编译器优化技术 Wiki： https://wiki.openjdk.org/display/HotSpot/PerformanceTacticIndex

最后我再说一句，语言级别的性能讨论，不是放在语言代码和机器码之间的编译器实现，而是去讨论，语言代码和最后行为之间的框架、设计模式、业务实现，完全取决于开发者水平和生态水平的，那我感觉这个讨论，从本质上就已经远离了计算机科学了，我甚至怀疑能发出这个争议的人是否是科班毕业

[VeteranCat]

@lesismal 额 那，祝你好运。 我一直认为 go 还是 java 之争这种东西在公司内部属于政治路线的斗争。 现在更是深以为然，项目能用 Go 跑就用呗。 反正我是不太推荐用的。 可能我还没遇到必须要用 Go 的场景吧。

[lesismal]

@diagnostics 我不想再讨论语言本身了

> 语言级别的性能讨论，不是放在语言代码和机器码之间的编译器实现，而是去讨论，语言代码和最后行为之间的框架、设计模式、业务实现，完全取决于开发者水平和生态水平的

我这个人比较注重实践，对于技术选型的语言选择，我建议不要只考虑这些理论上的如何如何，多看看实践，从开发到部署维护，从便利性到安全性到开销占用能效比。尤其是，拿实际项目中主要开发人员的普遍情况来对比，不要用一小撮高手才能搞出来的情况去对比普遍业务，因为绝大多数业务是普通业务开发人员搞出来的，例如 GC 算法最牛逼但实践中你不能指望所有人对分代 GC 都了如指掌搞得比 go 这种自动档还好用，Java 有很多不错的方案，但被用到生产实践优化的比例很小。


@wanqiangcrack 大厂很多 go 重构的，很多人说 go 只在国内火但外用的少，但 go 是谷歌造并且带头用并且云原生领域算是最火了，国内一票独角兽明星企业用 go ，抛开阿里这种传统业务已经重度绑死 Java 技术栈的不好调头，看看 b 栈知乎战略调整到 go 大量用它重构以前其他语言的，最近几年腾讯技术战略上也是转向大量用 go 的。如果你们的业务从没遇到过性能问题、复杂业务逻辑用 Java 不容易搞的问题、Java 安全问题、Java 部署麻烦硬件开销成本高的问题，Java 高手难招而且主要是 web 服务相关、其他业务就难招到高手 Javaer ，等等一系列问题，那对你来说可能确实只是政治路线之争，因为你们的业务不需要对 Java 进行优化。但实际商业中，不只是 web 服务，比如大厂各种云基础设施，各种分布式基础设施，各种不同类型的业务，尤其是商业注重成本收益比效率这些，在大厂海量业务下软硬件成本的放大效应全是钱的问题。Javaer 经常说的一句就是堆机器就行，但规模稍微大点的中型业务就可能上百台节点的集群，能省 30-70%的硬件成本就算不小的持续降本了，更何况大厂的那些基础设施可不只是这点节点数量。至少我在自己工作中和行业里那些选择 go （不一定是全部替换掉 Java 之类的，但很多新业务都努力上 go 、旧的其他语言业务也积极用 go 重构）看到的不是政治路线斗争，而是务实的商业+技术选型，而且我自己的实践中这个选型也确实降本增效（别听那些开箱姿势不对的人说 go 开发效率低，姿势用对了 go 的开发效率真没比 Java 差），而且安全性也更高了（这两年 Java 漏洞有点感人）

[diagnostics]

@lesismal #174 挑起语言之争的不是你吗？现在搞得好像我说 Go 垃圾一样，事实上我通篇都没说 Go 怎么样。

你说的少部分顶尖的人才能搞出来的情况就更搞笑了，有 JIT 压根都不需要你业务代码写得非常好，反而门槛比 Go 低多了，这也是你一开始的结论，Java 开发者普遍不知道底层。

我不清楚，一个前言不搭后语的人，能力到底有多强

[lesismal]

@diagnostics 抱歉，我可能前面没把不想继续讨论语言的原因讲清楚，那我解释下吧，我不想再讨论语言的意思是：我不想跟你这种人继续浪费时间，优劣相关我已经讲了很多，因为你只知道吹理论和那些不被大量常规使用的东西来对比，不看实践中的 java 硬件开销、性能、成本来对比，所以我觉得你的水准好像不太够，我不想拉低自己的水准去打这些口水仗

虽然我不想继续讨论，但是并不代表我反悔自己的观点，这跟前言后语没关系，所以你对我的前言不搭后语的推理也是逻辑有点奇怪了。前言后语搭不搭不那么重要，很多文学作品影视剧也看上去天马行空这一榔头那一斧子，但你理解了之后才发现原来那么有意思。技术的东西实实在在，理论不结合实际、逻辑不及格可不是好事情

至于能力，我知道自己不算多强，但我估计你的水平可能不足以用来评价我的水平。

如果不爽我，建议你 block 我好了，这是我最后一次回复你了，我也先 block 你了，免得大过年的浪费彼此时间

站长推荐的《 In Time 》也建议你看一下

[diagnostics]

笑死，嘴炮 java 垃圾，说的确实 Java 不节能，也就是云原生的浪潮下，养活了一批 “Go” 开发者，写了点相关的代码，造了个在 go 上的轮子就洋洋得意了，项目进 CNCF 了吗？ Description 写着 High Performance ，连 design principles 都没有，这就是高水平～

从头到尾，一句有用的反驳都没有，只有嘲讽，这就是国内 Go 开发者啊～

[diagnostics]

Go 开发者最爱的两件事：

- 碰瓷其他语言
- 造网络轮子

我在 v2 少说也 6 、7 年，在 v2 发的 Go 轮子，60% 和网络有关，20% 和 Web 后端框架有关，10% 可能是一些分布式协议的实现（例如 mit 624 就是 go 写 raft 吧？）

国内 Go 开发者其他领域有建树吗？甚至提分布式调度框架，还有人拿 go 代码量几乎为 0 的的 DASK 和 RAY 说事。。。我在想 2k repo 的作者都是这水平，那其他。。。。

[lesismal]

@lesismal #61
“这道理就像是，路上看到一坨狗屎，大家得躲着走，总不能要求别人上去尝一口然后才有资格说它臭吧”