磁带或者其他冷数据，适合归档类、资源类的数据备份。

实时业务数据、而且是别人家的业务、很多二进制格式的数据你都不清楚是啥的，咋备份啊？直接磁盘拷贝啊？每一秒可能都在变化，不现实的，而且即使定期拷贝磁盘备份，也解决不类中间时段的数据丢失问题。还得是业务方自己把鸡蛋放在多个篮子好些

分两类：
1. 同步的：使用 t.C 的地方配合了 select ，其他的 context 甚至 default 之类的可以先于 t.C 解除阻塞并 t.Reset ，这种依赖高版本可以解决问题。如果担心以为高版本没问题但实际用的低版本导致问题，可以自己封装下 Reset 用 select <-t.C: default 避免这种情况
2. 异步的：很多场景是<-t.C 与 t.Reset 是不在同一个协程，而<-t.C 与 Reset 可能发生在同一个瞬间，Reset 并不能保证先于<-t.C 返回，这样就需要额外的一致性保障、除非这块的一致性要求不大

大搞微服务框架的基本都是脚手架堆屎山。如果非要用微服务框架、让我打分，哪家封装的少简单易用哪家分数高，go-zero 这种大量搞营销、而不是真正提高代码质量的还是算了，随便扫下目录，比如：
core/codec 里放了 aes dh gzip hmac rsa ，加密、压缩、哈希算法放一块叫 codec ，你要是用这些组合起来实现个自己的编解码叫 codec 包也行，关键都是这些加密压缩哈希本身的简单封装、彼此之间也没什么关联，真的佩服
core/syncx 里把一堆标准库的强行再封装一些，比如 atomic cond_t ，标准库很多地方已经比较简洁了，一大堆这种强行二次封装，真美什么必要，我怀疑好未来是按代码行数评定绩效的吧，这么喜欢把简洁的 golang 搞成屎吗？
几年前大量的营销行为，净吸收小白 star 了，真是仗着国家人口红利造就高 star 的巨大屎山，非常讨厌这些搞营销的污染 golang 环境，之前没骂过，今天蚌埠住了

kratos 我没看，也没看到他们团队有 go-zero 那种大量营销行为，不做评价

很多团队，根本不需要复杂的微服务框架，你门做这种复杂框架选型的时候，然后又要去学习这些复杂的垃圾框架的基础知识的时候，别人功能都写好了上线了而且更加轻便、更加高性能、更加易扩展

go 的基础框架，web 框架一大把 gin echo chi fiber 之类的，rpc 你要喜欢就 grpc ，要是想更好体验就用我的 arpc 这种，log 框架也是很多随便选个 star 多的都足够好用，其他的什么服务注册发现都 etcd 自己需要就提供了稍微按照自己喜好封装下都可以，业务量没那么大服务没规模都不需要注册发现这些，甚至 web 服务里做好限流熔断之类的 limiter 连 rpc 都不需要

每次看见咨询微服务框架的尤其是推荐垃圾框架的，哎！
愁！

我个人：

1. 本地 go 用最新
2. 很少用新版新特性
3. 如果需要测试，命令行走起，https://go.dev/doc/manage-install

> 2. 有的 channel 不知道由生产者关闭，直接在主程序生产者还未发送结束就关闭结果 panic ；

这种面试题用一个 chan 可以，但但就这个面试题的功能的话似乎就没必要俩协程了，不需要用俩协程也就不需要用 chan 了。
所以这种题如果出给我、只是纸面作答、我是不知道怎么答只能空着，因为需求不合理。

很多基础场景生产者不是唯一的，可能会是并发多协程会生产，所以通常是应该把用于发送的和用于关闭的分开两个 chan 、用于 close 的 chan 再配个 atomic compareandswap ，避免用单个 chan 、某个地方关闭后、其他协程还在给 chan 发数据直接就 panic 了，一些粗暴的实现直接 recover 这种 panic 虽然也问题不大但毕竟它不是个好的处理方式、比如还得纠结 panic recover 是否再给调用者一个 ErrClosed 返回，还是两个 chan 好些。

另外，如果不需要清理 chan 内遗留的数，chan 本身用完之后是不需要 close 的。

@duty 谬赞了，谢谢🙏

@TanKuku Carbon 这个我不了解

@iceheart 也可以多看下内存不安全的 bug 漏洞，比如谷歌的：
https://cloud.tencent.com/developer/article/2396076

摘几句：
2022 年标志着内存安全漏洞的 50 周年。自那时以来，内存安全风险变得更加明显。与其他公司一样，谷歌的内部漏洞数据和研究显示，内存安全漏洞广泛存在，并且是内存不安全代码库中漏洞的主要原因之一。这些漏洞危及最终用户、我们的行业和更广泛的社会。我们很高兴看到政府也对这个问题予以重视，比如美国国家网络主任办公室上周[3]发表了一篇关于这个主题的论文。
——注意：内存安全漏洞广泛存在，并且是内存不安全代码库中漏洞的主要原因之一。

谷歌看不到 C++ 进化为一种具有严格内存安全保证（包括时间安全）的语言的现实路径。
——注意：谷歌认为 C++在内存安全这方面现在不行、而且未来也不行，而且不只是谷歌认为 C++不行，就没听说哪家认为 C++现在或者未来能行的。C 在这点上并不比 C++强，甚至更弱。

将所有现有的 C++ 代码大规模重写为一种不同的、内存安全的语言似乎非常困难，而且很可能仍然不切实际。
谷歌认为对于新代码和特别是风险组件，补充过渡到内存安全语言是重要的。
——注意：补充过渡到内存安全语言是重要的。对于内核，C 补充过渡也是一个道理。

报告中也可以看到，谷歌有大规模的 Java 和 Go 安全代码库，而且也在加大 Rust 的投入。

如果意识不到这些，可能是我们的视野局限于自己的小而美的工作范畴、思考的高度达不到那个层次所以看不到。内核不是我的工作领域我了解不多，Rust 也不是我的工作内容我了解也不多，但即使我喜欢 C 和 Go ，也不会那么自信，自信到把自己的技术观点放到与 linus 和谷歌等最顶尖最前沿的巨擘的对立面。

> 即使一个语言内部实现的内存引用计数，我也不认为这种东西该存在内核里边。

@iceheart 我不觉得引用计数是个问题，搜了下，引用计数在内核好像是挺常见的：
https://gist.github.com/carloscn/3f0179ecfa599969556e86eb80555266

c++的问题可比引用计数恶心得多，智能指针涉及引用计数的部分反倒是相对简单的，更大的容易产生隐含问题的在于容器和各种构造函数的结合，复制构造赋值构造拷贝构造，c++11 之后还有各种复杂的语法语义、左值右值还有 std::move 之类的，一不小心一个 size 比较大的容器触发了个什么复杂的拷贝就可能性能瓶颈或者深浅拷贝的问题，即使老鸟、面对这些复杂语法语义也可能拿不准、需要认真再认真才能确认。

rust 虽然也不简单，但比 c++好很多。

> 所以我的观点是有 c 就够了，保持简洁，不要增加阅读者的心智负担

我也喜欢 c ，但我前面楼也说过，c 越来越后继无人了，而且不安全的问题也没法解决。
至于简洁，c 简洁？小段代码、小项目代码，c 确实可以很简洁，但就内核来说，c 的一层层宏已经让人头疼了，不是难度大，而是记不住，想入门内核，先要硬拼一段时间记忆力才行。而这一点上，可阅读和可维护性上，rust 也是优于 c 的。

前面说的语言复杂性导致的 bug 或者副作用，c++可能造成更多、rust 也不能保证 100%避免，但 c++不只是复杂本身，更重要的是复杂背后可能造成的副作用本身。rust 也有背后的机制、但远未如 c++这般容易带来副作用，不只是背后机制的副作用，而且写代码的人对语言本身的理解就是很大门槛、由于过于复杂的 c++而导致更大概率搞出带有副作用的代码。

而且请你注意，别人引入 rust 的最大侧重点好像是内存安全，rust 在复杂性问题上远远优于 c++、甚至在这种超过临界阈值的大工程里 rust 简洁性也优于 c 、在内存安全上完胜 c 和 c++。

所以复杂性问题，对于 rust 可以忽略，因为复杂性不大而且并没有因为复杂而带来更多副作用、而是用这点复杂去更大程度上解决内存安全等问题，你说的点是不太成立的

> 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 本身有问题、它的定位是实现协议并提供基础接口。