@x940727 我铜币不够了，你先看下你引用帖子日期吧，其他的我明天说

@x940727

"不了解就是 Go 的 GC 整体比 Java 强"
—— 我不了解 java，但是了解 go，从 java 的 jvm gc 表现看，go 确实强。比如 stw，比如高阶需要手动去调 java gc 策略然而即使调还是 stw 时间比较长，比如 java 吃内存，号称宇宙第一 gc 算法，然而同时也是宇宙第一吃内存怪兽。go 的 gc 自 1.8 以后已经非常强，而且除非代码本身 cpu 打满之类的否则基本不会有所有线程 stw 的情况，并且单个线程 gc 时长也比 java 小，如果这都不算强，那 java 这种号称 gc 算法最强但实际效果拉垮的 gc 赢了我 go 辩不过

"你知道 ElasticSearch 就是 Java 写的吗？"
—— 我上面已经说过了，这是历史原因，go 出生的晚，如果 go 早生，java 就不会如今这么繁荣了。但是话说回来，go 也是站在以前很多语言肩膀商取其精华去其糟粕，比如像 java 的臃肿、嘴炮 gc，go 就当成糟粕而没有采用，而是在 c lisp 之类的简洁基础上更加简洁、借鉴 erlang 之类的并发模型但又不限于 actor 所以让编程姿势更加通用，编译上除了动态链接库那是没办法、静态链接库直接打包到二进制内方便部署。优点很多，不一个一个说了。
ES 是 java 社区较早的积累，而且这种重量的基础设施不只是简单的语言实现、还涉及到整个社区的培养，所以不可能像 F 那样相对轻量的项目可以迅速替换掉 L 那种。
用这个举例，跟你之前用头条招聘举例子是一样的，没有辩论的逻辑性。比如我之前说用 F 替换 L，是能证明 java 有的项目不行所以用 go 取代。但你举出 ES 的例子却不能说明是 go 没能力去取代，而是 go 没有适合的时机去替代，尤其是 ES 这种社区、商业都发展的比较成熟的项目。
单就网络库、框架，我上面问你的那些，我都搞过多年了，java 虽然不熟悉，但是也手撸过 java 的网络库，c/c++/go 的都撸过，进程池、线程池各种框架层的东西、性能优化都是我日常工作内容

@x940727 同步 io 与异步 io 什么区别？ select 跟 epoll 什么区别？ java 同步库跟 NIO/Netty 什么区别？互联网最早期时进程池模型线程池模型就是同步 io，为什么后来又要搞异步框架？异步 io 你有深入了解过吗？读相关的书或者看优秀项目源码甚至自己手撸过吗？ CSAPP，APUE，UNP，内核相关的书，java 高并发网络相关的书，或者其他的优秀的系统层网络层优秀的书有真正认真读过并且理解了吗？
至少从前面几楼你的一些措辞，确实是基础认知的欠缺，如果没有花很多时间在我提问的这些上，建议多研究下，可以等先去确认下自己搞懂了再说

@x940727

"不然并不会比那些很快的同步 Web 框架差多少的"
——这里提到的 "那些很快的同步 Web 框架" 是指哪些框架？恕我见识少，还没听说过有高性能的同步框架（跟之前提到的一样，这里的同步是指同步 IO，不是指 erlang/golang 这种语言级同步）

@x940727

[普通并发量 go 还是有优势，写起来简单，不容易写出瓶颈，java 如果不异步性能太差，netty 了又 callback hell]
——java 我肯定是不熟，但是 netty 异步 callback 应该没问题吧？我前面这句话有什么问题的话，请你指正。

@x940727 go 的 gc 整体表现还真是比 java 强，而且特定业务或者框架用 pool 优化，内存、gc 更优。我自己那个库，就用了大量的 pool 优化。我们很多项目也是很多语言，对比 java 和 go 的项目，go 内存、cpu 占用各项指标都吊打 java 。

"为什么头条现在也在大规模的招聘 Java 的程序员？"
——兄弟，分析问题要学会逻辑理清晰一点。大规模招聘 java 不等于不继续用 go，完全没有证据表明字节没有继续大量用 go 。而招聘这个主要涉及几个方面，一是业务线，比如偏向电商、后台、企业级等 java 已经有成熟的社区积累的，市场上也有大量的该领域的 java 从业者，反观 go，一共才诞生了多少年，社区和从业者数量没得比，字节这种业务扩张猛的，想大量招 go 的人都招不到，然后优势 java 成熟领域，何必招 go ？反而是性能敏感的领域，比如中间件、云服务这些各种基础设施，你看有几个用 java 做的？包括比如以前 ELK，现在都变成 EFK 了，为啥？你 java 的 logstash 太渣了啊！而且这还只是 go 出生太晚，如果跟 java 同时代出生，怕是没 java 啥事了，很多 appache 顶级项目怕是会用 go 实现了

"Java Servlet 同步性能依旧不好的原因就是因为在对象的生命周期中做了太多的事情"
——我不了解 java servlet，但是你们之前提到他是非异步的。如果你们确定他是同步的、阻塞 fd，那这太基础了，阻塞 fd 对线程资源的浪费肯定是影响响应的最大因素（除非你故意写对象生命周期巨大消耗的示例、让对象生命周期这些的影响超过阻塞 fd 的影响）。

@kksco
"缺点也有，c/c++ 大佬想掌控一切的路就被 runtime 堵死了，比如像 nginx 这种亲核性就没办法实现。"
——我这搞了一份 poller 的，协成、线程数量仍然可控，业务协程数量可控并且可以做到业务代码同步、网络层异步、性能、内存各方面的平衡：
github.com/lesismal/nbio

只是：go 的指令、runtime 、gc 这些，确实让 go 性能比 c/c++还差很多

更多细节有在另一个异步库 gev issue 中做更多的阐述：
github.com/Allenxuxu/gev/issues/4

@x940727
＂不是 java 不异步性能差＂
——这是最基础的错误认知，所有语言都做不到同步还性能强的（这里的同步是指 fd 阻塞 io，不是指接口同步，go 标准库是 fd 非阻塞但接口同步的），因为同步意味着进程 /线程占用，而进程 /线程数量有限，你 fd 阻塞 io 随便就让线程池都在那等来等去的，处理频率大大降低。所以单比性能的时候不只是以前 c/c++吊打 java 阻塞 io 的框架，连 nodejs 都吊打。
既然知道 netty 强，你就应该了解为啥强，如果不异步还能高并发高性能，那 erlang/golang 之外的语言还搞异步出来干嘛？


"如果单论语言性能，Java 是要强于 Go 的。"
——醒醒。不同消耗对应的指令性能，java 和 go 各有千秋，但是整体算下来，java 并不比 go 强。

夏天容易支帐篷，因为 long and hard 戳坏了吧。

普通并发量 go 还是有优势，写起来简单，不容易写出瓶颈，java 如果不异步性能太差，netty 了又 callback hell

go 标准库方案面对海量并发时协程数量、内存消耗、调度和 GC 等开销太狠，干不过 netty

我写了份异步库，应该可以干得过 netty：
https://github.com/lesismal/nbio

日几十亿这种提法应该是业务、运营数据这样吹牛比较好。对于技术，最好落到 qps/tps 之类的，这种才能算是性能指标。不信你算一下，10 亿请求每日，相当于多少请求每秒：
>>> print(1000000000/24/3600)
11574.074074074073

才 1 ｗ多，二八原则，我算你峰值 10-20w 每秒。这种瓶颈在于数据层的承载力，不在于框架层，比如我上面自己的框架，4c8t 的单节点几十万连接数，echo 压测照样能跑十几、几十万 qps

@hitmanx

And Torvalds hasn't indicated whether he would approve the pull request (PR) to merge the latest Rust for Linux patches into the main Linux kernel.

linus 也只是对这个提交中存在 panic 不满意，并且你发的链接中下文中提到恐慌问题已经解决了：

Ojeda acknowledges Torvalds' concerns about panics, but also says the team of developers attempting to bring Rust to Linux are addressing the issues.

He says that removing unnecessary panics is a key concern amongst the Linux kernel community, but believes that it is "mostly a technical obstacle and has been solved."


我上面回复中说的 "开始接受” 可能不够准确，正式 merge 后可能更准确些，但估计只是时间问题

而且，还有其他的一些的新闻，比如：
https://www.theregister.com/2021/07/05/rust_for_linux_kernel_project/

看副标题：
Torvalds reckons 'it might be mergeable for 5.14'

linus 之前的观望到对 PR 中代码问题的指正、提交人员的修复、考虑可能合并到，这个变化过程，跟 C 版提交是类似的，至少没像 c++那样连机会都不给，而是已经在走流程，只要 rust 语言自己别浪出什么幺蛾子，内核正式接受 rust 应该只是时间问题，毕竟天下苦 c/c++久矣。。。

@bluesenzhu

rust 吹这么多年，做出什么杀手级项目来了？
—— tidb 这些或者其他什么项目都可以按下不表，单就内核开始接受 rust 这件事，当年 cpp 也被努力过入内核、但是 cpp 没机会的


你们都忘记了 c++在某种程度上继承了 c 语言的哲学：相信程序员
—— 这个逻辑非常不对，你要是再往前推，打孔卡时代连编译器优化都没有、岂不更相信程序员？
因为编程语言发展的早期，语言之父们也没有当下这么多的语言设计经验，他们已经实现了从机器语言、汇编语言中解放生产力的目标，而相信程序员——只是语言发展早期不成熟带来的错觉、副作用，或者说是当下该语言没有朝着更高阶演进、大家必须更大程度地自己去控场而“为赋新词强说愁”，为了奶 c++而给 c/c++扣上相信程序员的高帽、自欺欺人罢了

rust 非要踩 c++上位？
—— 这还不是 c++自己不争气，如果 c++争气，根本就不会有 rust 诞生，也不会有 go 诞生。层主可以去了解下为什么 firefox 要搞 rust 、为什么 google 要搞 go

我不打算再入手 rust 了，也不是 rust 粉丝，但是对于宗教狂热这个词，层主可能比其他几位 rust 粉更狂热。

@lesismal #194 必坑指引 -> 避坑

补充，effective/more effective 以及类似的书，虽然是一些工程上的总结、给 cpper 带来了很多必坑指引，但也正是这些书，更加让孔乙己们深陷于茴字的 N 种写法无法自拔。虽然即使没有这些书，孔乙己类的人仍然会成为孔乙己，但是如果有其他的朴素工程哲学的书籍先入为主，或许能挽救很多 cpper 于水火，或许能让 C++不至于走上如今的道路。毕竟 c with class and stl，或者再来点 template，就已经足够做事了。

才看到，原来 #44 就是楼主回复我，这么缺乏逻辑的推理能力可能就是老员工搞这出的原因之一。

不必那么脆弱，逻辑需要加强。

@Mrun 我说 linus 喷人的意思是互相喷正常，我后面的“如果”是补充说明，因为楼主并没有介绍更多可以辨别是非的情况。

@Turkestan ”linus 不也喷人“就是拿这个老员工跟 linus 相提并论——这个推理不符合逻辑。而且我后面有“如果”

@wutiantong
我个人也没有觉得 C++难，只是收益率太低了，书也无需推荐给我，我家里 C++的书恐怕 30 本不止，C++ Primer 这本书被严重夸大了，名不副实，稍微有用点的 effective/more effective，最喜欢的是对象模型，因为我写 C，不喜欢 C++那些隐藏的手段想弄清楚究竟。efficient/more efficient 、模板、侯捷 stl 源码、boost 各种系列，还有很多其他的记不起来了，太久远了都十几年前买来部分阅读的的书了，当然还有 BJ 老爷子那几本

C++的主要问题是收益率：
1. C++十年磨一剑 vs Java 三年架构师，这两个人群整体的工资、收入对比，这是对于个人职业发展的角度的考量。
2. C++项目研发周期、项目维护、团队维持的难度、日后新业务迭代的速度 vs 其他语言，除了那些本身就需要性能为主的偏基础设施或老项目或其他一些既定领域已有解决方案，很多商业项目等不起 C++的节奏，等到 C++搞定天下，工资早倒闭了

不管是个人职业规划还是商业项目，都讲究收益率，而且也并不是所有人都觉得 C++不难，反而，大多数人会觉得难，也不是难在“难于理解”，难在需要花大量时间，多数人没那么多时间或者舍不得花那么多时间。

以上说的 C++问题，这种类似的讨论，以前在老论坛行也有接近 C++语言律师级别的大神经常讨论，至少是十年前、还没有 C++11 的时候大家就基本共识了

再提醒下为什么你们几位一再挺 C++，你们没有错，但是你们可能不自知（比如我之前提到的，你们解释的问题根本不是其他人在说的问题）：
经济学有个词叫“沉没成本效应”，百度抄一段：“指为了避免损失带来的负面情绪而沉溺于过去的付出中，选择了非理性的行为方式。根据经济逻辑的法则，沉没成本与制定决策应是不相关的”，解释一下就是，如果你花费了大量的成本在某件事情上，舍不得放下或者承认他的不好。
你们在投入了大量的学习成本之后，不自知地要维护 C++，否则就是否定自己的过去，而且目前仍旧可以用 C++做着喜欢的项目、获得不错的收入，但是，如果你曾经用于 C++上的钻研如果是换做其他领域，收益率可能远高于当下（当然并不是针对所有人，你可能是最优秀的那少数、收益率仍然非常高，我这里的意思是针对群体整体）。

当未来某天你们跳脱出 C++的范畴，发现更多新大陆的时候，蓦然回首，再去比较，才会发现原来这世间有那么多比茴字的六种写法更有趣的玩物

linus 不也喷人呢吗

如果我代码确实有问题，我就发愤图强，不给或者减少给比人这种机会

另外老员工如果是出于对项目特别负责的原因，分享、警示大家代码需要注意这些问题，没毛病。如果都不让说，等哪天出大事故了，全团队跟着加班加点熬夜处理之类然后再扣银子、开人之类的就更惨了

保持对技术的敬畏，如果不是故意或者明显的被针对，也不用玻璃心去考虑这些，继续研究技术干就完了