@XTTX 我针对的是你 #9 那句 “standard libs 都用一种方式是有原因的”，BTW 你看懂我引用的那几行代码是哪里的没。。。你仔细看下，那不是我自己代码，那个就是 go 源码，你所说的 std libs 不会是不包括 go 源码吧？

@gogogo1203 #28 上一楼是回复 28 楼，写错了写成 20 。
补充一下，我没花多少时间故意翻源码打脸之类的，因为平时就经常源码，也正是因为以前就隔三差五在源码中看到类似的写法，所以看到 #9 说只用一种方式的时候，才会第一时间觉得不严谨。

今年完善了一份 poller 的框架，几年前比较火的一个老外的关于 golang websocket 百万连接的帖子和相关的 gobwas/ws 都是存在缺陷的方案，我这个实现了完整的异步流解析 tls/http1.x/websocket，能够解决 golang 1000k 问题。对比其他 golang 非阻塞 io 框架，他们都还没有支持这些，并且单就网络库部分的性能，基本高于其他库，易用性扩展性都更强。吹个牛逼说，目前全网独一份，不信你可以去看 evio/gev/gnet/easygo，还有字节的 netpoll，或者也去找找有没有其他库，做下对比，看看他们有没有支持这么多功能。
或者不必功能支持完整度，单就性能对比下：
https://github.com/lesismal/go-net-benchmark

这些花费了我很多时间，还在持续打磨，社交确实会消耗很多精力，所以才会有 #26 反思。你如果觉得我很闲，可以粗略看下我的几个库相关的，再看看我是不是很闲

当然，对于这个帖子消耗了这么多时间，确实是犯二了，我继续反思。

@gogogo1203 #20
1. 我的确不用这种方式，但是你能看懂 #10 是回复的这句不：“standard libs 都用一种方式是有原因的。”？我希望既然聊技术严谨一点，不要没怎么看过源码就随口说源码怎么样，或者其他类似的观点，因为大家信誓旦旦言之凿凿的观点，可能会对其他人造成误导。
2. 不是翻帖子，而是之前就看过那个帖子，感觉一楼可能还相对经验欠缺、讨论技术的时候自己没太搞懂知识点就随口说了，然后加上我上一条看到他说的这个观点，所以觉得应该回复一下，但是回复了几次，一楼都没有说清楚到底他说的 “standard libs 都用一种方式是有原因的。” 中的这种方式是指什么，或者也可能我理解能力太差、一楼已经在后续回复中讲清楚了但是我没 get 到，如果是这样，那各位可以指正，我虚心接受。
3. 我上面回复了帖子，对方在我下一楼没有 at 任何人，我也没太关注他们之前的讨论，而且我下一楼的回复中的内容也可以用来回复我的内容，并且语气带着轻浮，参考我本次回帖第 2 条中的出发点，所以觉得有必要多回复一些。
4. 你确认圣母这个词符合你用在这里的场景吗？

另外，如果本来帖子与我无关、我自己“强行对号入座”，那我对号入座跟阁下又有什么关系呢？而且我前面几次回复中也解释过了为啥我会回复好几段。你倒是也挺有时间得嘛，或者你可能也没仔细看我前面回的内容没分析我和一楼多次对话中的内容吧~

@XTTX 小伙子心态蛮好的，我喜欢，大过节的，不吵了，没必要，如果造成不适，我抱歉，请见谅。但该严谨还是建议严谨

反思，反思，少回帖，只在 V 站攒积分少 BB 。虽然还是想知道 “std 里只有一种” 到底指的是什么，但是我放弃。

我昔所造诸恶业，皆有无始贪嗔痴。

戒骄戒躁，继续安心写自己喜欢的东西，向站长学习。

站长说的对，不要浪费时间在没意义上的人和事情上。观点都描述不清楚，到现在都没听明白你到底是说 named 还是 naked，自己也没 at 别人刚好在我楼下而且语气可以被当成是回复上面相关人的，自己都不反思下表达能力么。
怪不得编译器厂招聘帖子里一堆人怼你

block 了先

@XTTX
第一，你一楼不管是指 named 还是 naked，我个人都没想反驳，挺对的。但后面提到的 std 里只有一种，用词太武断了，所以随口回了一句。
第二，这个语法，虽然别扭，但并不是什么高级玩意，你 #12 的语气，是带着不屑的，对于不是什么高级货的东西的不屑，没什么必要，真要是牛逼的东西你懂别人不懂，那你狂忍你狂，我举双手支持你的强。但这点玩意如果也觉得值得炫耀的，那可能是出于瓢的阶段了，刚好又是在我下一楼以为是回复我，所以才会连回了几个。

这个帖子浪费我太多积分了，不再回复了。有兴趣的欢迎来我的项目交流：
github.com/lesismal/nbio （可以拿 evio/gev/gnet，以及 gobwas/ws 等来对比看看）
github.com/lesismal/arpc
相关话题（压测请不要看各个仓库展示的数据，以自己代码实测为准）：
colobu.com/2021/08/01/benchmark-of-rpc-frameworks

@XTTX #19 如果这样讲的话，那你也看一下，你在之前有提到过 naked return 吗？你看看一楼没有提把？你一楼的更让人想到的是返回值那里的变量声明而不是 naked return 。js2854 #10 的回复也是声明相关的而不是 naked return 。如果要细聊，那就聊明白点。而且，你确实没有 at 我进行回复，但是刚好是在我下一楼，你谁都没 at，我以为是回复我呢。即使不是回复我，你贴出来的链接，或者可以用来以上与你相关的所有人？那沟通技巧也可以提高下。想让别人看清楚再来杠，自己也要尽量把事情说清楚，否则别人也很难看清楚。

另外，对于我个人的感觉，函数定义的地方的返回值声明，比 naked return 让人阅读障碍更大。

再另外，你看下我贴的这个：
github.com/golang/go/blob/master/src/bufio/bufio.go#L169
你再往下看几行，std 到底有没有：
github.com/golang/go/blob/master/src/bufio/bufio.go#L174

纸上得来终觉浅，不要只看一些观点性的东西就轻易下一些结论

@XTTX tour 里说的是建议性的并不是说 std 里没有，我第一次是回复你 #9 "standard libs 都用一种方式"

@XTTX 另外，虽然源码里算常见，但我个人也不喜欢这种写法，自己代码里基本不用。

@XTTX 其实你可以看看源码的，随便找了两个常用的 pkg：
https://github.com/golang/go/blob/master/src/bytes/buffer.go#L180
https://github.com/golang/go/blob/master/src/bytes/buffer.go#L199
https://github.com/golang/go/blob/master/src/bytes/buffer.go#L236

https://github.com/golang/go/blob/master/src/bufio/bufio.go#L169
https://github.com/golang/go/blob/master/src/bufio/bufio.go#L207
https://github.com/golang/go/blob/master/src/bufio/bufio.go#L295

我没看过你发的那个，平时习惯了源码。

@darrh00 你要考虑，如果是 c/cpp 那些，要自己写信号量 /条件量+queue，虽然也是简单的玩意，但对于逻辑程序员占 80%的程序员群体中的这大部分人，已经是一道天堑鸿沟了，chan 可以让你直接拿来就用了。

稍微复杂点的功能都可能需要去处理并发相关的事情，真的不算事。所以你说的缺点，可能对于长期做 web 接口开发 CURD 人员来说，确实是难了点。如果都是按照 CURD 的标准来要求开发者，那很多基础设施类的东西都没几个人能做了。即使是其他语言很方便，但承担造轮子任务的人仍然要面对大量的复杂。

chan 的这点复杂，应该是自己级别飞升时必须克服的一道基本功修炼流程，而不是被这么点复杂把自己逼在舒适区里只靠业务经验提高履历含金量。

@XTTX #9 go 源码里这种还是挺常见的

不要归咎内卷于普通员工级或者小领导级的个人头上，首先应该主要归咎于资本，其次归咎于爬到高处的领导级个人。

有的人是出于兴趣：因为写代码和学习相关知识确实很有意思、让人着迷，很多编程思想、知识都是带有艺术性的，新技能 get 时或者自己实现一些好的事物时会产生愉悦和满足；
有的人是出于责任：工作任务在肩上，出于责任心事业心去努力是优秀人才的基本素养，普通员工和小领导这种级别的，通常还没到非常恶心地大面积杀伤队友的程度，最多也就是受到资本和更高层领导胁迫锁做出的内卷行为，面对要么卷要么走的艰难境地，他们也是无奈之举、也是受害者；
有的人是出于贫穷：城市家庭的孩子，通常条件不至于太差，这里不是说父母给买房买车那种才不算太差，而是真正贫困的那种，比如偏僻地区的农村，那真的是交学费都要耗尽父辈的洪荒之力、真的是家里多个孩子只能供其中的部分孩子完成学业梦想、真的是要靠助学贷款馒头就咸菜勤工俭学之类的才能完成学业，当然现在这种会越来越少。比如某 500 强，招聘偏爱农村出身的，为啥？因为这部分小伙伴为了翻身真的能够坚韧、吃苦耐操。如果换个城里的小伙伴，八成干不了多久就跑路了，对于企业人才养成成本不友好。

资本天生趋利避害追逐利益最大化，高级一点的领导也都有股票期权分红之类的了、属于资本的帮凶了。

如果去归咎于普通员工、小领导，这本身就是底层人民的内耗，反倒帮助资本转移了矛盾，就像很多人喷外卖员、快递员不送货上门，换位思考下，如果资本不各种算法压榨得他们喘不过气来，大家自然都愿意服务周到客客气气皆大欢喜。

所以，仍然摸爬滚打在底层的话，就彼此放过吧，顺应国家整治 996 趋势，团结起来去让资本减少作恶吧！

@shoaly @pzzrudlf
开了个 slack 频道，欢迎来交流：
https://join.slack.com/t/arpcnbio/shared_invite/zt-vh3g1z2v-qqoDp1hQ45fJZqwPrSz4~Q

Shutdown 只是减少了停服的短暂过程的抖动数量，对于当时 qps/tps 非常高的服务效果好点。但仍可能存在在途请求（网络链路、尚未被读取的内核缓冲区中的数据）被放弃、请求方失败、超时的情况。

所以虽然冠以了 graceful 之名，只是 part of graceful，仍然需要业务层来保证需求的实现，以及集群架构层面的高可用性部署、调度等相关支持，业务逻辑相关的重试、幂等保证是必需品。

即使不是程序本身的导致的抖动，也存在其他网络链路抖动的影响比如 ISP 线路故障，仍然是需要集群架构层面的高可用性部署、调度等做相关的强支持，而这些支持能够同时从更高层面照顾到程序引起的抖动造成的影响。（ ISP 、程序抖抖可能造成请求方重试、累积踩踏雪崩之类的，都是需要网络、运维、高可用部署相关的这些保障）

有了业务和运维层面的保证，对于绝大多数业务量级而言，程序引起的短暂抖动其实影响很小。而对于中小厂的流量，抖那么一下，受影响的请求数也是极小的。

所以其实 graceful Shutdown，虽然照样用，但实际发挥的用处不大。

顺便蹭蹭，欢迎关注我的两个框架，高性能、海量并发相关：
https://www.v2ex.com/t/794435#reply3

lz 女朋友是时候考虑下退掉楼主、继续考察另外两个谁留下了。

捡芝麻丢西瓜。

网络层可以用我这个：
https://github.com/lesismal/arpc

微服务就是多个服务，他们之间怎么管理，自己设计实现接口就行了。

@vicence 我#7 少打了个 T，没法编辑