@byte10 求“高手”不要黑我ｇｏｌａｎｇ

golang

```golang
package main

import (
"context"
"fmt"
"io"
"net/http"
"os"
"os/signal"
"time"

"github.com/lesismal/nbio/nbhttp"
)

func onEcho(w http.ResponseWriter, r *http.Request) {
data, err := io.ReadAll(r.Body)
if err != nil {
return
}
if len(data) > 0 {
w.Write(data)
} else {
w.Write([]byte(time.Now().Format("20060102 15:04:05")))
}
}

func main() {
mux := &http.ServeMux{}
mux.HandleFunc("/echo", onEcho)

svr := nbhttp.NewServer(nbhttp.Config{
Network: "tcp",
Addrs: []string{":8080"},
MessageHandlerPoolSize: 256,
EnableSendfile: true,
}, mux, nil)

err := svr.Start()
if err != nil {
fmt.Printf("nbio.Start failed: %v\n", err)
return
}

interrupt := make(chan os.Signal, 1)
signal.Notify(interrupt, os.Interrupt)
<-interrupt

ctx, cancel := context.WithTimeout(context.Background(), time.Second*3)
defer cancel()
svr.Shutdown(ctx)
}
```

多读几本好书就理解清楚了，C 的细节还挺多呢，这么零散着问，很难系统吸收知识点，建议猛读一下我推荐的那几本书

国人写的印象中《 C 语言深度解剖》还不错，太久了，记不清了。还有本《狂人 C:程序员入门必备》我没看过，但是当初作者在论坛跟大家 PK 各种 C 问题，很多老伙计一块给提了不少勘误和意见，内容应该能靠谱些吧

刚还搜到一本日本人的《征服 C 指针》，也没读过，但是以前读过的一些日本作者的技术书籍，感觉都挺不错的

《 C 陷阱与缺陷》《 C 专家编程》《 C 和指针》了解一下

@lesismal 再补充一点，也正是 go 基本成型、可以被大家广泛采用之后的时间段，py 之父离开了谷歌。虽然没有人直接说是什么原因或者把 py 之父跟谷歌的语言技术栈变革直接关联，但是那个入职离职谷歌的时间点，恰恰对应了 py 、go 在谷歌内部的发展情景，即使非直接影响，也是从侧面可以看出谷歌 go 、py 的大体发展过程

另外，其实楼主对 go 的一些描述，说明楼主对 go 真的还太不了解，对 go 的观点可能还停留在 5 年前

@Mark24 #10
我在前面给出了这句："除非自己不打算往更高层次提升、去有机会处理超大业务量级"

其他方面的楼主说了一大堆，但是兄弟，你可能没 get 到为什么那些巨头要用去换掉 py 、php 。可以搜些帖子、新闻，稍早点的 B 站用 go 重构大量服务，往前大概还有七牛、猎豹移动、滴滴、头条大量用 go，或者我上面发的那个知乎的那个改造应该是近期一两年内的，好像前年还在知乎上看到有人说知乎 py 性能垃圾然后知乎技术大佬出来回复有好方案愿意怎么样怎么样的

py 不只是国内这些巨头在海量业务时要抛弃，十几年前谷歌造 go 的时候是因为被 c++虐得快瓶颈了，再往前有点谷歌把 py 之父招到麾下了本来是打算让 py 能帮助谷歌解决很多工程上的问题，但是搞了几年，没办法，py 虽然是真的方便但也是实在太慢了，谷歌根本无法忍受 py 这种性能。
不要用 py 在大数据、AI 等领域仍旧遍地开花来解释 py 性能不是问题，你要看看 py 在这俩领域是怎么使用的——都只是胶水语言 bind 个 c++之类的接口而已。另外就是 devops 领域了，然后呢？还是主要用于非性能敏感领域的工具、简单服务。真正涉及性能的，k8s 也好，周边的 netdata 、filebeat 也好，都是 go 、java 之类的（早期很多人用 java 搞了很多东西，但是后面很多是用 go 比如 EFK 的 F 替代 ELK 的 L，因为 java 的性能和吃内存也是让人无法忍受的）

还是上面那句话："除非自己不打算往更高层次提升、去有机会处理超大业务量级"
至于你解释的那些，兄弟，你首先得搞懂 py 自己的瓶颈是什么、为什么在那些领域被大家抛弃了，然后再来讨论时你的论据才会更具说服力，但是我相信，如果内真的去了解了那些内容，你直接就会站到我这边的观点、不需要再为 py 争取什么了。

某乎社区核心业务 Golang 化实践
https://zhuanlan.zhihu.com/p/48039838

"好了现在你已经知道如何去选择，或者说学习什么样子的技术框架。"
——对于 pyer 、phper 之类的服务端开发者，最正确的选择是转 go/java，除非自己不打算往更高层次提升、去有机会处理超大业务量级

看看近几年的各大明星企业大量用 go 起步或者用 go 重构的情况吧，连知乎都用 go 重构了

即使使用云盘，重要数据也应当自己备份。
并不是云的问题+1

出门左转，golang 欢迎你

上联：你走你的阳关道，安全去西北
下联：他过他的奈何桥，容易上西天
横批：道不同不相为谋

如果是我，趁早散伙， :doge:

值得看，看这种书需要讲究方法，否则硬啃效率低：
详解更偏学术，不好啃，可以先看图解 tcp/ip
1. wireshark 的书或资料也找些，wireshark 抓包配合着看协议栈，会容易理解和加深理解，比起只啃书事半功倍
2.《 UNP 》网络那卷最好也带上，顺便看一些系统函数和编码，加深理解
3. 《 Web 性能权威指南》也挺好，也看看吧

@no1xsyzy #34
设计模式之父是 GoF，他们并不承认这一策略的失败，并且似乎还在宣传？
你说 G.Alexander ？我盲猜他会认为你（称他为设计模式之父）是在侮辱他。
——按你说的这个 Gof 对 G.Alexander 的借鉴关系，我觉得 G.Alexander 才算是之父，Gof 这种坑害社区的存在，更加不配之父的名头
建筑和软件最大的共同点都是工程属性，但设计模式在软件领域的发挥威力比在建筑领域的发挥威力更加困难。
专业的建筑团队，建筑施工前画图纸、数学物理的公式计算、材料的实验、还有安全等各种流程的把控，要比软件工程规范得多，因为那都是人命关天的事。并且建筑建造完成后，日后建筑主体也不会大改。软件工程就不一样了，除了成型的领域，更新迭代太快了，而且 if else 的分之太多，多数产品出了事故也不是什么闹出人命的特大责任事故。
所以，在建筑领域这种相对更容易发挥设计优势的场景，人家的之父都承认实验失败了，软件领域却还嗨得飞起，只能说社区里有伪布道师们的市场，就像保健品、传销一样。

楼主根本就不是一个聊法，逻辑性太差，不跟他这浪费时间了

以上所有打字直到现在，我确实心里没什么波澜，算是平和的。
中毒这种说法是因为早年也跟不少 cpp 语言党聊过太多了，cpp 中毒太深的人过度玩弄语法语义和各种特性，cpp 里也有不少乐于搞设计模式的，一个单例能搞出 6 种还是 8 种实现。然而实际的架构设计、工程设计、算法设计、结构设计却不到位，导致日常夸夸其谈，项目问题不断。
这些多年撕得多得出的结论，而且也因为撕得多，所以早就平和了。

就像无法叫醒一个装睡的人，执着于语言特性、设计模式的好多人，也难回头，所以我称之为中毒。
经济学上讲，是因为“沉没成本效应”。在程序员这种职业上体现出来就是：自己花了不少功夫在某些知识上，舍不得承认这些知识的无用，并且继续对它学习研究，从而遮了眼、阻碍了自己的提升。
就比如设计模式吧，@no1xsyzy 见识广博，#21 里已经提到过了，设计模式之父自己都承认实际效果并不那么好。你再掰开了揉碎了仔细思考，真正有用的一些设计模式，比如观察者 /发布订阅，这种总结出来确实不错，但是大多数的设计模式真的未必有用，反倒是误以为宝贝的人，反复琢磨把玩、浪费了很多时间。比如单例模式，除了 java 这种一切皆类、必须通过实现单例或者直接 static 变量（不方法不优雅）才能使用这个公共变量的方式，其他语言基本都是一个公共变量就完事了，最多再加个显示的初始化或者作为函数返回值，让调用的方式看上去有一点虚伪的逼格而已。再比如工厂系列，最初知道这竟然是一种设计模式的时候，我都不好意思笑，多自然的一个事情，构造函数写舒服点就是工厂系列，非要整个单独的 createXX 之类的也行，设计模式之父自己都承认了一些事（我没去考证真假，但从设计模式实际的效用上讲，我觉得他应该承认过），我们大众何苦为难、作践自己呢。。。

设计模式和 go，我这么多认真回复，我觉得是“买椟还珠”，你作为卖家拿设计模式当个珠，用 go 的 demo 的盒子把它装里面了，而我是为了 go 这个盒子而来，真没 care 过设计模式

甚至于面向对象，大概 1996 年 cpp 标准委员会那帮老头子们开会就在聊“面向对象被社区滥用了呀”

再说点设计模式和面向对象的问题。社区已有的积累，可以继续吃老本，比如企业级、电商之类的，尤其是 java
但是良好的 OO 抽象体系也好、易扩展也好，在面对高速发展、快速迭代的产品和需求面前都不那么好使：
面向对象的鸭嘴兽问题，使得在很难预期大部分未来需求前提下，无法完美抽象、只能做到当下的抽象、无法做到未来的易扩展，设计模式同样，那些以为现在这样有哪些好处，未来可以怎样易于修改的好处，当不确定的未来真正到来的时候，很难发挥出其预期的优势，反倒可能因为早期的臃肿设计导致后续的修改难度更大。
真正有效的方案是进行阶段性重构。如果团队业务更新太快、疲于奔命，阶段性重构的频率就要降低、周期就要拉长，就得等到长时间日积月累后毕其功于一役。
今天为了以后易扩展做了很多更复杂的设计，明天可能因为非预期内的变化导致修改难度更大。所以像 go 这种不重语法糖特性和模式，反而专注于让事情简单化的语言，却成了工程性更好的选择

你应该能够从 go 语言本身感受到并且再深入思考一些：为什么 go 不天然面向对象？也不重设计模式？也不在意那些花哨的语法糖？
go 已经是站在那些以往优秀语言的巨人肩膀上，如果那些东西真的那么好，难道 c 爹和 rob pikez 这些老头子是老糊涂了？——这帮老头子们真的是老中医，切脉稳准狠，开出了 go 这副方子，让我一副药下肚，码欲大增、秀发得保，虽老矣，为心所愿之代码，尚可稍废寝食

然后我的疑问来了，既然用 go 了，你的意思好像又说你只写 go，那是谁带你跑偏去研习设计模式的？
把你引入歧途的人，是人性的扭曲还是道德的沦丧。。。你得喷他啊顺便把他也带回正轨。。。

@xiaoxuz
如果实在觉得用 go 举例子不影响看球，那多举点例子：

一把杀过人的普通菜刀赠送给邻居，邻居不会愿意要，觉得不吉利，是不是应该强调菜刀只是道具跟杀人没关系？
赵薇日本军旗，军旗只是拍时尚照道具而已，赵薇不应该被喷，军旗也没毛病？

如果道具在一切场景都可以解释成只是道具、不影响用来做什么，那这世界就不会存在忌讳了。

天不早了，晚安

@xiaoxuz

上一楼语气还看着正常些的，说翻脸就翻脸，淡定点。

要是真侃技术，咱就聊技术的，别扯远了，我这也一直聊的技术，别扯什么中医不中医的，你看看#18 楼你几句回复，看上去认真在回复似的，但是都是在把话题扯远了、没在正题上。

既然用 go 举例子，还不能让别人说了？而且设计模式本身的很多臃肿，并不限于 go，我从 go 开喷只是因为你用了这么臃肿的 go 代码做示范。你要说用 go 做示范但是是为了设计模式、跟 go 没丝毫关系和影响，这逻辑就像莫文蔚穿个啥乳 h 品牌然后强调自己只是打广告跟乳 h 没关系类似的道理，然后还不允许别人喷

你要是没用 go 举例子，如果我点进来看一眼是 java 我转身就走了，头都不回，因为个人不喜欢 java 觉得 java 不值得我浪费时间、毫无兴趣，但是我也不随便就喷 java，因为不只是一个人的 java 臃肿

还有不是要安利什么的说法，我在之前楼里也说过了，你都写文章这么正向推介了，还解释不是安利作何？没必要的，安利了就安利了，你认为对、拿出来大家聊，越辩越明就完事了。逻辑搞清楚点，别聊技术又不正面应对又不承认这不承认那的，也别给别人扣帽子什么中医

还有，关于私货这个，如果只是简单提起+一个链接，你说 xr 之举也就算了。但即使私货，我也带上了大段的内容，希望能有人看到、从中吸收一些知识点，对于宣传知识贡献开源而言、没什么不好意思的，做这项目也不是为了钱，到了职业年龄末段了，只是想给社区一些回馈、给自己留些念想，如果幸运能多来点人到仓库看看、用用甚至再来点 issue 、pr，那更开心了。但是说句失望的，就这么段内容，能 get 到点的人非常少，一是别人也未必认真读到我这段内容了，二是别人之前不知道这个问题相关的这么些信息，三是确实是有些难度。你反手看看其他一些异步网络库，只做自家业务比如游戏的 tcp 协议异步库也就算了，但是对于 http/websocket/tls，数千 star 那些，基本没有支持的，都是玩具。

最后，既然写文章发出来了，就要接受你的受众的反馈，既有正向的又有负向的，零差评是几乎不可能的事情，不要那么在意面子，太在意面子，即使能在面子驱动下搞好技术也气大伤身、没必要。如果实在在意，可以先内修、等心态更平和的年纪再把文章发出来

@xiaoxuz
现在我有主观态度了： 爱看不看，话太密！ 你写 go，不能证明你可以代表所有 goer~
——　对，这一点我非常赞同。你写你的，我认为不好的我就提出来，不让某个观点独霸市场。各有说辞，其他人看了也才能有更多思考、减小误入歧途的概率

另外夹带个私活，我自己的异步网络仓库，已经支持　 http1.x/websocket/tls：
https://github.com/lesismal/nbio

以往有些老帖子，golang websocket 百万连接相关的，引入 poller 通过事件的方式控制数据读，不用为每个连接都分配一个协程，进而降低海量并发场景下协程数量过多带来的的巨大内存开销和调度成本。
这些方案对应有 gobwas/ws + easygo/netpoll 之类的框架。
但是他们都做错了，只是把 fd 加入到 poller，读事件时进行读取完整的 http upgrade request/websocket message，但是读取过程中如果该连接数据只到达一半，该读取过程将阻塞，进而造成该连接所在的 poller 的 event loop 阻塞或者专用于读取的协程池协程被阻塞占用，这种连接多了则服务相应速度变慢甚至不可用，如果协程池 size 大于连接数，则异步网络网络库减少 goroutine 数量的目的就达不到了
实际要解决问题，需要的不只是异步 io 接口，更需要的是粘包解析，nbio 的实现方式是解决了这些问题的，欢迎试用