@Rorysky
“和 c 一个地位”是我没有说清楚，我想说的是以前很多人都认为 rust 只能用来写内核模块，是没有办法编写具体的系统功能，但是不是这样的，rust 也是被编译成 o 然后像是 c 一样进行链接，根据这个原理把某个 c 函数完全替换成 rust 实现是没问题，例如 drm panic qr 功能就是这么实现的。

后半句“但是不需要学 rust”的意思是，虽然 rust 理论上实现 syscall 也没问题，但是现在 rust 首先并不是强制开启的，并且想开启 rust 只能使用 LLVM 工具链，因为 gccrs 后端发展了这么多年也还是一个残废，再加上社区其实还是有极其排斥 rust 的人存在。
综上在未来的很长时间内是不会出现例如内存分配/回收这种系统核心部件的个功能需要开启 rust 支持才能使用的这么一个情况。rust 也就只能用来写写驱动，例如 Android 上的 binder 驱动就用 rust 重写了，因为 Google 本身就在 Android 项目用到了 rust ，甚至一些核心 service 都是 rust 写的，rust 重写 binder 也就无可厚非了。

至于为什么 rust 还是被合并到主线了我的看法是。
1. 内核开发苦 c 语言久矣，c 语言由于羸弱的表达能力，原始的类型系统，导致非常容易出各种低级 bug ，例如读并发数据忘记加锁了这种情况，但是也许就是这么简单的一个 bug 最后就会被一层层精心构造出提权攻击。所以忘加锁，忘加引用计数，设计上只读的变量被不小心改了，读了一个被释放的地址等这种低级问题很容易通过 rust 解决。
2. 此外就是内核开发者年事已高，精通 c 的，精通 Linux 开发的也越来越少，需要引入新东西吸引新一代开发者。
所以在 1 的基础上引入第二语言的话几乎没有其他选择，首先就是 cpp for linux 已经被毙了很多年了，因为这玩意首先比 c 难学，其次就是黑魔法太多对 review 造成了极大困难，最后就是没办法禁用某些功能。除了 cpp 好像也就 rust 和 zig 了，zig 现在还是 unstable ，也就只能 rust 了。
3. rust for linux 的早期版本其实很有想象力，为了向世界展示出 rust 功能，抽象出了很多很多的 api ，甚至对 socket 的读写还实现了 async ，但是被正经的合并到主线之后这些都被毙了，开始进行了漫长的“完美”重写，不过这种重写也并发完全是偏执狂的自我感动，当时有很多设计确实有问题，例如因为 mutex 是原地初始化的，new_mutex 甚至是 unsafe 操作，而现在引入了 pin-init 库之后确实更加完美了。
所以综上即使现在的 rust for linux 有各种各样的问题，但是好像也只能这么搞了，希望未来这个项目能人手多一点，偏执狂少一点，该 unsafe 的就 unsafe 得了。

我来科普下现在 rust 在 Linux 内核里是什么情况吧，有可能一些地方会说错。

rust for linux 对内核里的 c api 进行包装抽象，搞出 rust 形式。
但是由于内核中的 c api 抽象成 100%rust 风味的代码十分困难，所以这个项目搞了这么多年也很难说是可用，甚至其中的块设备层的抽象存在很大的问题，我还写文章进行吐槽了下 https://zhuanlan.zhihu.com/p/1945592808326013494
Asahi Linux(Macbook 上跑的 Linux 发行版)的做法是对用到的 api 抽象出 80%够自己用的，但是这种代码没办法被合并到主线，Asahi 也只能独立维护内核。

rust 的代码和 c 是一个地位，比如 panic drm qr code 功能中就会见到 drm_panic.c drm_pacic_qr.rs 在一个文件夹中，rust 代码负责计算然后导出函数供给 drm_panic.c 进行调用，但是更多的还是用于模块的编写。

至于 contributor 是完全不需要学 rust 的，因为以后的很长时间内是不会存在 Linux 中的某个功能是 rust 写的，不会 rust 看不懂的这种情况。

你问 ai 的时候记得把 crate 的版本也给带上，大版本之间可能有 breaking change 。
新开项目正常的话都是用最新版本的依赖。

又到了我最喜欢的 flutter vs RN vs uniapp 环节了。

@shinonome 而且这种错误里包值的做法是非常场景的，为此 go 还内置了 errors 包替代这种手动转型和判断。

你需要的是把数据包装到错误中。
```go
type MyErr struct {
value int
}

func (err *MyErr) Error() string {
return "MyErr"
}

func test(a int) (int, error) {
if a%2 == 0 {
return a, nil
}
return 0, &MyErr{value: a}

}
func main() {
_, err := test(1)
if err != nil && err.Error() =="MyErr"{
fmt.Printf("error %d\n",err.(*MyErr).value);
}
}
```

其实都 25 年了，这个话题已经没什么好说的了。
微软的 Windows ，Linux 的 rust for linux(虽然这个项目在我看来是有很多问题的)，甚至 Android 中不少核心服务都是 rust 写的，还有 aws ，cf 等公司都开始用 rust 了。
这可以说明 rust 已经成熟到可以用来编写一些“正经”的东西了，并且国外的大公司也都在积极使用 rust 。但是基本都是用在偏底层和基础设施的领域，假如你的方向和这些不沾边，比如是搞 gui 前端 后端方向的那学 rust 真的没什么用，只能 just for fun 了。

@stinkytofux 编译器都向下兼容，特意强调要学 cpp 11/17 是因为这些新标准加了很多很多新语法，新东西，让 cpp 更现代了。要是只学 cpp 98 标准的话别说面试了，开源项目的代码都看不懂。
并且就 cpp 这块多顽固不化的公司到现在也都会使用这些新标准了，比很多公司万年 java8 要好不少。

https://rosepinetheme.com/ 这个最近在用还不错

个人感觉粉蒸肉才是最懒人的做法。

叶公好龙罢了，真让你用 c 写项目一写一个不吱声。

就在 Linux 内核里看到过，这么用的比较多
#define page_folio(p) (_Generic((p), \
const struct page *: (const struct folio *)_compound_head(p), \
struct page *: (struct folio *)_compound_head(p)))

你这个是 watchdog 报的硬死锁 Hard LOCKUP ，说明系统没办法响应中断了。
你这个情况发生的地点就是文件缓存回写最后调用到的块设备层，最后调用到的 pvscsi_queue 的 spin_lock_irqsave(shost->host_lock, irq_flags)这句，这句中会关闭中断，并且得不到锁太长时间最后 watchdog 报的错。
这种情况我认为很大概率就是被虚拟化出的设备太多了，导致单一租户的吞吐率降低，让其余用到了这个锁的代码发出硬件命令的时间变长导致锁迟迟无法释放，最后导致的这个问题。
反正治标不治本的方法就是关闭 watchdog 了。

周一喷 rust 傻逼，邪教社区，语法复杂，lifetime 傻逼，unsafe 治标不治本。
周二喷 go 错误处理傻逼，泛型傻逼，Google 傻逼。
周三喷 cpp 傻逼语法复杂东西多，cmake 傻逼，标准演进慢，委员会不行。
周四喷 web 技术 js 傻逼，ts 更傻逼，html 和 css 就更不用说了，写代码像是糊屎。
周五喷 flutter dart 傻逼，性能不行，issues 一堆不解决，快被 Google 放弃了。
周六喷 c 傻逼，表达能力低，ub 多，bug 满天飞。
周日吹 ai ，可以解决上面全部的问题。

soul 上真是各种托，上次还碰见个酒托，说是要喝酒，问就是去 xxx 酒吧，美团一看那个酒吧下的评论不少都是被酒托骗的。

我记得闭包或者 async 块这种是没法打断点的。

你主力系统又不是 Linux ，当然没什么用。。。

设想下平行世界中加了新的错误处理的 Google 会怎么说。

我们尊重开发者意见，为 go 增加了新的错误处理机制，让这个已经有 10 多年历史的语言重新焕发生机，我们知道可能会有很长时间转型的“阵痛期”，但是这一切都是为了更好的 go 语言进行服务。
过去的几年中 go 语言的变化很大，经历了泛型，range over func 等重大特性，并且这次引入的全新错误处理，我们相信 go 语言可以持续的焕发生机，迎接新时代的挑战。
我们是持续拥抱变化，尊重开发者的 go 团队（狗头