只是用于上网的话，nginx 就挺好啊，caddy 的性能和消耗之类的还是不如 nginx 的

刚想回一句主题相关，一看 id 有点眼熟。
看 append 里的然后回帖从头看到尾，没觉得别人回复有怎么算阴阳怪气，但是已经被 OP 觉得逆鳞了，目测 OP 年纪不大自己喜欢阴阳怪气吧，怪不得聊技术都不讲逻辑，不论别人说什么都听不懂，不浪费时间是对的，这下真 block 了

我比较笨，多是随遇而安，到现在都不知道自己用的双拼还是全拼还是什么。。

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

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

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

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

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

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

@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 漏洞有点感人）

我选二手企业级氦气盘，16T 不到 1000 ，8T/10T 也才 500 左右

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

@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 容易上手、也不需要依赖太多轮子就能把项目搞得很好

@wanqiangcrack #167 忘记 at 了

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

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

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

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

@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 版本的开销和性能，可以来找我，价钱给到位，个人水平有限不是一定能搞定，但还是可以搞搞试试看的

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

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

@diagnostics

> 你见过哪个 Java 爱好者天天去碰瓷别人的？

兄弟，碰辞这个词用得不对了吧？

你看你自己原话都说了是批判的啊：“谈到编程就喜欢把 Java 批判一番”

怎么逻辑都不讲了呢。。

@Livid 我怕自己忍不住继续陷到语言之争里，求站长大大把我禁言几天。。。

我对 java 的评价一直很差，以上言论虽然是实话实说但对于一些同行来说可能有些刺激，如果管理员要处罚我，我认罚、以后本论坛里我尽量少喷 java 。

@byte10 所以对我而言，java 这种没有系统编程能力、性能有限、臃肿直到宇宙尽头、非常浪费硬件的“垃圾”，根本不值得我去浪费时间深入了解它，所以我并不那么了解它。这道理就像是，路上看到一坨狗屎，大家得躲着走，总不能要求别人上去尝一口然后才有资格说它臭吧。。。

@byte10 Hi 好久不见！
当年 golang 还没成熟的时候，我写 c/cpp 觉得有点累，于是手撸 NIO 被 java 的臃肿恶心到了，然后想想还是继续撸 c/c++算了，golang 成熟了我就撸 golang 了。
性能这个，同样的看我前面楼层，别说语言指令这种，要用大家常用的对比。可能跟老 php py 这些比是要强些，跟 nodejs 、go 比应该都是被吊打。剩下的也只有所谓的生态优势，但对于 curder 来说其实主要是行业技术栈优势，例如电商、企业级已经有那么多 java 那没必要重新造一遍，但这并不是别的语言不能搞、而是它还算稳定所以没必要重新搞，它占领市场早所以岗位多罢了。但是新生领域或者说需求变化快的领域，它也并不具备优势，所以直接头条 b 栈猎豹移动七牛各种新兴势力倾向 golang 。抛开这些行业选择它的历史优势，很多 java 不适合的，例如云原生。还有一些虽然用了 java 实现的基础设施、但其实如果用其他语言会比它效果更好，同样也是历史原因罢了。

另外，javaer 遇到“复杂”点的问题容易懵逼，例如系统知识，怎么排查网络、数据库各种。我不是说所有 javaer 都不懂，而是相比于 c/cpp/go 这些，javaer 不懂的人的比例有点多。言必称希腊，聊技术就是框架、全家桶、八股文。当然，我不是针对 java ，脚本语言的人绝大多数也基本都这样。并不是怪这些开发者不求上进，而是因为 java 社区就流行这种氛围，见过太多八股文选手，背了一大堆，侃知识点说的头头是道，离开八股文范畴面试问他点深入的就容易 game over 。
我也看到过很多 javaer 自己总结：背会了很多八股，但结合实际了却不知道怎么应用。

再说下 java 性能不错，比如 2018 年那会我门一些兄弟部门业务重构由 java 切到 go ，切换后对比了下，业务量还是原来那么多，他们对比了重构前后的消耗，以前 java 的内存消耗大概是 go 的 2-3 倍，cpu 消耗是 go 的 1.5-3 倍，响应时间 go 略好但整体上倒是没差太多基本可以忽略，因为并不是把服务硬件指标跑满、主要时间都是花在数据库上。别人喜欢用重构后消耗降低了多少百分比，但百分比看上去就好像是节省了一个比例罢了，反过来看，假设以前是 go 、切换到 java ，硬件成本直接翻 2-3 倍，这个情景就比下降的百分比更明显了

@yazinnnn0
也可能是 java boy 技术还不够深入、经验还不够丰富的阶段、get 不到 java 有多差
golang 虽好但毕竟性能还是达不到极致，java 的香，用郭德纲的话说，全靠同行衬托

@lsk569937453
#1 单比较语言指令 cpu 消耗那些，不同测试项的确是各有千秋总体差不多。但是 java 离不开社区全家桶，当 java 都用这些东西的时候，实际生产项目的性能确实挺差的

#11 也不算上升到品味，也不是饭圈。而是实事求是、确实是品味有问题