去 IOE，建议放弃 oracle 呢。

如果你们项目可用直接用 websocket 的话，如果用俺的 arpc，连 api 都可以省了：
https://github.com/lesismal/arpc/tree/master/examples/webchat

https://github.com/lesismal/arpc/blob/master/examples/protocols/websocket/jsclient/hello.html#L27
https://github.com/lesismal/arpc/blob/master/examples/webchat/chat.html#L80

大而全的微服务框架不适合中小团队直接拿来用，而大团队自家定制、不太需要用别人的

单就 RPC：
https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/
帖子中的性能数据可能不准确，最好自己跑那个代码实测下，易用性和各方面优劣可用自行对比

R9000K 　感觉不错

程序员这行，三十岁，累点的公司，鸡儿都立不起来了

有些东西看上去很美。

函数式编程没什么实际营养，当你以为得到了宝贝时，其实是误入了歧途。

@x940727 go 不无敌，但 jvm 确实垃圾。

@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 粉更狂热。