> rust 自动内存管理不是该更令人担忧吗？

@iceheart rust 的和自带 runtime 和 gc 的自动内存管理完全是两码事；如果跟 c++比，rust 更内存安全而且也不像 c++那么复杂没那么多隐藏的黑魔法，现在和以后都应该不会有比 c++更复杂了。

c++老鸟就更不要提了，最该反对的就是那些所谓的 c++老鸟搞出一大坨 c++11 之后的所谓现代 c++代码，老鸟是 happy 了，让后来人怎么玩？语言本身比要做的东西还复杂，整天把心智浪费在语法语义的讨论上，隔三差五一个 issue 讨论这个语法/语义这样用有没有问题？
现代 c++最大的毛病就是十年不出门，出门也是恶心人。

linus 拒绝 c++进内核不能更赞了。

> 反正等着这群老 B 死就行了,反正内核开发几乎没有新血.

@chenqh 你行你上，你去搞个能直接替代 linux 都可以。如果现在的 Rust 人能直接搞个新的我也是支持，但问题是目前也没哪个 Rust 团队能搞得定这么重要庞大的基础设施、而且最关键的是已有的社区依赖，全世界多少设备在上面跑着呢，不是过家家说换就换了。

前人栽树，后人纳凉，应该懂得感恩，而不是一边纳凉，一边骂娘，这种骂娘并不能显得自己高明，更不能显得自己高尚。

@iceheart #17 c 和 c++只是部份相近，但几乎完全是两种工程风格，实际工程中并不相近。而且 c++背后的隐含的小动作太多了，即使是老鸟也要谨小慎微，内核这种吹毛求疵的场景、用 c++一不小心就搞出大事、还不如 c 更加安全可控。而 c++相比于 c 的便利几乎不值一提，尤其是，c++并没有解决 rust 能够解决的内存安全问题。

> linus 虽然前段时间因为封杀俄罗斯的事情，有点败人品。

@TuxcraFt 人在江湖，在那个位置，总会有很多牵扯，没必要用平民事不关己看客的身份去吹毛求疵大佬们的这些无奈之举

> 这一次不管是 Linus 还是 Christoph 表现都令人失望。

@namaketa 所以只要观点正确，随便去社交网络发小作文是好事情、linus 应该大力支持并且也跟着去发作文大力支持？
但凡仇恨、反对、阻挠 Rust ，linus 当初直接就拒绝 rust 了，还用得着给你演这么多？


> R4L 的维护者改用 C 是更妥当的解决方案，看不出一定非要 RUST 的理由

@wwhc 虽然推进 Rust 主要原因是内存安全，但我个人觉得更重要的是，C 越来越后继无人了

多数人都不懂的一切从实际出发，即使背会了八股、实际工程中还是不擅长运用。
微服务只是一种架构设计和工程实践方案，关键是适不适合用、怎么用、用的对不对。

2015 年左右微服务刚开始要兴起的时候，我在好多技术群里喷那些无脑微服务的人，注意，是喷那些无脑微服务的人而不是喷微服务本身。
早年没有微服务的时候就有分布式，是更广义的概念，微服务被 web 领域的人把分布式更加领域细分并且搞了一大坨以 web 领域为主的基础设施。但其实游戏行业大型游戏系统很早就用分布式，只是游戏技术没有 web http 这些相对统一的协议和技术栈、而多是一家公司一套框架，所以游戏行业的技术相对 web 领域而言像是一盘散沙，也难成固定流派，开源的游戏服务器架构没几个好用的。

整天在那纠结这个概念那个概念，从来没去思考下这个方案与实际工程结合是否合理，你们 95-99%的人都错了。

好的现象是，一些大厂团队和一些老鸟逐渐开始清醒，但也是局限于实践中的那些好坏的点才后知后觉，但如果懂得思考，这些很多坑都是可以提前预见的。
软件工程领域，绝大多数所谓的架构师最大缺点，就是没有像土木建筑数学等领域，去做更详细的建模、图纸设计之类的，只知道 tmd 跟风只知道画点漂亮的所谓架构图甚至 ppt 忽悠老板，但凡知道思考实际的事情、这些大多问题、不是指所有问题，而是排除掉高精尖难度大的那部分，因为现实工程中绝大部份问题都是普通问题，其实都是可以像幼儿园搭积木一样，提前摆弄摆弄就清晰了。

只背八股，不思考工程实践，写再多文章都是误人误己。

四项基本原则：
1. 自己不要抽烟
2. 自己不要买烟
3. 自己不要送烟
4. 自己不要发烟

抽烟的都是敌人，十六字诀：
1. 敌抽我躲：敌人抽烟离我近，我躲开避难
2. 敌送我拒：敌人送烟做礼品，我拒绝收受
3. 敌发我声：敌人发烟一块抽，我声明不喜
4. 敌病我劝：敌人呼吸道生病，我劝他戒烟

库克库存大师不是白叫的，你以为是电子垃圾，但其实是心理学，大家骂 16E 就对了，这样就会有更多人忍不住去给 16 去库存了。
厨子心里美滋滋

@yiqiao go 的代码没像 java 那么臃肿，这种审美问题，符合团队的标准和自己的喜好不影响效率就行。如果已经在用并且习惯了，不改也没问题，实用主义

> 是的是的 孩子 你是对的

@laikick 其实如果自己不会好好说中文的话，可以完全去混非中文圈，看到过别人喷你、这不是糟蹋自己嘛，何必呢

@laikick golang-standards/project-layout 这个根本不算是好的结构：

而且这个 repo 作者可以算是 go 社区里最不要脸的了，我都不敢用“最不要脸的之一”来描述他、怕“之一”不准确：
https://github.com/golang-standards/project-layout/issues/117

请做个好人，不要再向别人推荐这个带来更多误导。

@liaohongxing 看了下提交日志，这个应该就是 gorilla 那个 fork 过来之后改了改的。不论哪个库，主流都是 http upgrade 到 ws 的，这个过程中的 hijack 后 ws 库就接管了 conn 。fasthttp 这个基于 gorilla 那个、后续改了多少内容我就没关注了，应该都差不多。我上面说的很多人使用 gorilla 有问题是指自己封装的部分的问题比如僵尸连接、协程泄漏，不是说 gorilla 本身有问题、它的定位是实现协议并提供基础接口。

@voidmnwzp 是的、当初好像是 archive 了一段时间，然后 fasthttp 和字节家都 fork 了分支，但后来 gorilla 又活了

BTW ，gorilla 被用的最广，但涉及到广播的，仍然需要自己封装，要注意避免循环中的阻塞，这通常需要自己封装额外的写协程，就是这个地方，我见过很多人实现的有问题，比如实现的不好导致僵尸连接

按照协议分层来讲，其他是实现 websocket 协议，melody 是基于 gorilla 之上的对 websocket 的封装，使用上方便些。

按照为了解决的问题分类，gobwas/ws 和 nbio 是为了海量连接数的场景，为了解决标准库方案在高承载量场景下的内存 OOM 和 GC STW 问题、节约更多硬件成本、让服务更稳定。
但 gobwas/ws 本身的设计和实现是存在缺陷的，因为它的 IO 接口仍然是阻塞的，所以 IO 循环中如果有 1 个或多个慢连接就会导致其他连接也跟着排队，个别欧洲团队用它做内网还凑合、因为内网爆这种问题少，但公网没那么稳定，所以非常不适合用于公网商业项目、属于冒险行为。nbio 没这个问题。

coder/websocket 号称很多优化很快，但实测、跟其他基于标准库连接的方案相比，算是性能最拉垮的了

相关内容和测试：
https://www.v2ex.com/t/945827
https://github.com/lesismal/go-websocket-benchmark

300%也还是慢...

踏踏实实的技术帖, 比隔壁凭借哪些特质走到现在可是赞太多了

@sthwrong @kekeabab #24 #25 没什么好办法, 又何止是工作, 程序员至少还是逻辑比较强的, 生活中的更多人和事情比这还折腾. 改变不了, 气也没用, 不如平和, 效果反倒会好些. 应该庆幸的是自己不是这种, 自己已经是极少数的优秀了, 如果心态能平和, 自己会更厉害.

@lujiaxing #8 绝大多数都是普通人. 会用梯子和懂你说的那些也并不能代表牛逼, 老外很多你说的这种"菜鸟", 对这些人而言, 写代码这只是一份工作, 他们挣钱享受生活, 很多这种人家里条件都还可以, 他们自己没生活和钱的压力所以不需要卷技术. 除了具体技术问题要争对错, 怎样的技术追求和技术节奏, 并没有什么必要去批评. 我年轻时候也跟你一样, 眼里看着很多菜鸡老司机程序员啥也不会, 心里也很鄙视, 直到闲聊发现, 比如一个同事, 刚毕业工作家里就给买了 180 平的房子奥迪宝马两个车换着开后来老被同事议论觉得太高调了不好又买了个便宜车用来上班开, 比如另一个同事不只是啥也不会而且还很笨他自己倒是挺想学技术的但学很慢甚至学不会, 但是他家深圳开农家乐而且那半个山是他家的.
做自己喜欢的事, 让自己活得幸福, 珍惜自己重视的人, 其他的, 不那么重要