@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 不也喷人呢吗

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

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

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

除了那些少量设计有量、层次和模块相对稳定，并且开发人员严格控制的项目，比如内核
而多数项目中，面向对象、设计模式都解决不了长期迭代后代码变屎山的问题，周期性重构才行

cpp 是在把屎山堆得更大，而 rust 相当于对它的重构

@lesismal “tr1 boost 是青少年”指 boost 早期的时代

#128 @wutiantong

@no1xsyzy
“特性是 GC 、没有竞态条件、没有锁、Actor 异步模型、严格的变量可用性”
——　如果保证这些，那实现这些的每一点都是以牺牲性能为代价的，甚至我怀疑它会降级为脚本、类似 py GIL 伪多核