linus 不也喷人呢吗

如果我代码确实有问题，我就发愤图强，不给或者减少给比人这种机会

另外老员工如果是出于对项目特别负责的原因，分享、警示大家代码需要注意这些问题，没毛病。如果都不让说，等哪天出大事故了，全团队跟着加班加点熬夜处理之类然后再扣银子、开人之类的就更惨了

保持对技术的敬畏，如果不是故意或者明显的被针对，也不用玻璃心去考虑这些，继续研究技术干就完了

除了那些少量设计有量、层次和模块相对稳定，并且开发人员严格控制的项目，比如内核
而多数项目中，面向对象、设计模式都解决不了长期迭代后代码变屎山的问题，周期性重构才行

cpp 是在把屎山堆得更大，而 rust 相当于对它的重构

@lesismal “tr1 boost 是青少年”指 boost 早期的时代

#128 @wutiantong

@no1xsyzy
“特性是 GC 、没有竞态条件、没有锁、Actor 异步模型、严格的变量可用性”
——　如果保证这些，那实现这些的每一点都是以牺牲性能为代价的，甚至我怀疑它会降级为脚本、类似 py GIL 伪多核

@ipwx
你们几位老鸟说的都是 cpp 这样或者那样用没问题。

但问题是：
假设 cpp 诞生后的 c with class+stl 是婴儿，tr1 boost 是青少年，c++11 及以后算是成年。
越来越少的人有精力坚持到成年，快速发展的行业里爆发增长的业务需求没有时间等 cpp 项目上线和缓慢的迭代，那样子可能版本还没发出来公司已经倒闭了。
并且通常来讲，c with class stl 已足够做项目，我就是保持停留在这个阶段，否则就可以直接宣布 c 去死了。

所以你们说的不是问题中的问题跟其他人说的问题根本不是在聊同一个问题。

“如果不用 xx 代码量会 5w”之类的，也不是什么问题，代码量多了一点，但是直观、可读性的提升，可以让更多使用婴儿 cpp 的人接手和维护，否则你看吧，招个人都费劲，说不定再过二十年，招懂 cpp 11-39 的程序员，就类似美国那个什么需要招 cobol 古董程序员求而不得的情况了。

老项目、性能敏感领域、团队技术栈等因素考虑，cpp 确实还有很多市场。但对于新项目，即使性能敏感，如果团队能力 ok，rust 确实是更好的选择。性能不极度敏感的，go 是更好的选择。

@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: