@bluesenzhu

rust 吹这么多年，做出什么杀手级项目来了？
—— tidb 这些或者其他什么项目都可以按下不表，单就内核开始接受 rust 这件事，当年 cpp 也被努力过入内核、但是 cpp 没机会的


你们都忘记了 c++在某种程度上继承了 c 语言的哲学：相信程序员
—— 这个逻辑非常不对，你要是再往前推，打孔卡时代连编译器优化都没有、岂不更相信程序员？
因为编程语言发展的早期，语言之父们也没有当下这么多的语言设计经验，他们已经实现了从机器语言、汇编语言中解放生产力的目标，而相信程序员——只是语言发展早期不成熟带来的错觉、副作用，或者说是当下该语言没有朝着更高阶演进、大家必须更大程度地自己去控场而“为赋新词强说愁”，为了奶 c++而给 c/c++扣上相信程序员的高帽、自欺欺人罢了

rust 非要踩 c++上位？
—— 这还不是 c++自己不争气，如果 c++争气，根本就不会有 rust 诞生，也不会有 go 诞生。层主可以去了解下为什么 firefox 要搞 rust 、为什么 google 要搞 go

我不打算再入手 rust 了，也不是 rust 粉丝，但是对于宗教狂热这个词，层主可能比其他几位 rust 粉更狂热。

@lesismal #194 必坑指引 -> 避坑

补充，effective/more effective 以及类似的书，虽然是一些工程上的总结、给 cpper 带来了很多必坑指引，但也正是这些书，更加让孔乙己们深陷于茴字的 N 种写法无法自拔。虽然即使没有这些书，孔乙己类的人仍然会成为孔乙己，但是如果有其他的朴素工程哲学的书籍先入为主，或许能挽救很多 cpper 于水火，或许能让 C++不至于走上如今的道路。毕竟 c with class and stl，或者再来点 template，就已经足够做事了。

才看到，原来 #44 就是楼主回复我，这么缺乏逻辑的推理能力可能就是老员工搞这出的原因之一。

不必那么脆弱，逻辑需要加强。

@Mrun 我说 linus 喷人的意思是互相喷正常，我后面的“如果”是补充说明，因为楼主并没有介绍更多可以辨别是非的情况。

@Turkestan ”linus 不也喷人“就是拿这个老员工跟 linus 相提并论——这个推理不符合逻辑。而且我后面有“如果”

@wutiantong
我个人也没有觉得 C++难，只是收益率太低了，书也无需推荐给我，我家里 C++的书恐怕 30 本不止，C++ Primer 这本书被严重夸大了，名不副实，稍微有用点的 effective/more effective，最喜欢的是对象模型，因为我写 C，不喜欢 C++那些隐藏的手段想弄清楚究竟。efficient/more efficient 、模板、侯捷 stl 源码、boost 各种系列，还有很多其他的记不起来了，太久远了都十几年前买来部分阅读的的书了，当然还有 BJ 老爷子那几本

C++的主要问题是收益率：
1. C++十年磨一剑 vs Java 三年架构师，这两个人群整体的工资、收入对比，这是对于个人职业发展的角度的考量。
2. C++项目研发周期、项目维护、团队维持的难度、日后新业务迭代的速度 vs 其他语言，除了那些本身就需要性能为主的偏基础设施或老项目或其他一些既定领域已有解决方案，很多商业项目等不起 C++的节奏，等到 C++搞定天下，工资早倒闭了

不管是个人职业规划还是商业项目，都讲究收益率，而且也并不是所有人都觉得 C++不难，反而，大多数人会觉得难，也不是难在“难于理解”，难在需要花大量时间，多数人没那么多时间或者舍不得花那么多时间。

以上说的 C++问题，这种类似的讨论，以前在老论坛行也有接近 C++语言律师级别的大神经常讨论，至少是十年前、还没有 C++11 的时候大家就基本共识了

再提醒下为什么你们几位一再挺 C++，你们没有错，但是你们可能不自知（比如我之前提到的，你们解释的问题根本不是其他人在说的问题）：
经济学有个词叫“沉没成本效应”，百度抄一段：“指为了避免损失带来的负面情绪而沉溺于过去的付出中，选择了非理性的行为方式。根据经济逻辑的法则，沉没成本与制定决策应是不相关的”，解释一下就是，如果你花费了大量的成本在某件事情上，舍不得放下或者承认他的不好。
你们在投入了大量的学习成本之后，不自知地要维护 C++，否则就是否定自己的过去，而且目前仍旧可以用 C++做着喜欢的项目、获得不错的收入，但是，如果你曾经用于 C++上的钻研如果是换做其他领域，收益率可能远高于当下（当然并不是针对所有人，你可能是最优秀的那少数、收益率仍然非常高，我这里的意思是针对群体整体）。

当未来某天你们跳脱出 C++的范畴，发现更多新大陆的时候，蓦然回首，再去比较，才会发现原来这世间有那么多比茴字的六种写法更有趣的玩物

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 和指针》了解一下