Linux 内核爆发 C / Rust 大战，核心开发者愤然离职 - IT 之家
www.ithome.com/0/830/010.htm

我建议 RUST 开发者直接开发新的内核再争论吧，毕竟使用 RUST 开发出安全的内核，需要安全的语言+安全的开发，缺一不可。不是说语言安全就够了。

？张口就来

我最近看到的一个 comment 是, rust 底层调用的 c 库是不安全的, 所以导致... rust 啥时候成熟啊?

t.me/CE_Observe

订阅一下, 看看下面的评论

我现在的心态是, 看事大不嫌热闹. 哇咔咔.

也许随着 linux 内核一起成熟吧

前几天 v2 相关讨论 hesudu.com/t/1109794

www.zhihu.com/question/11940762516/answer/99152469629
你可以看看这个回答，这次事件根本不用绕到 c 和 rust ，单纯就是因为人的原因和技术政治原因。
本质上就是假如 Linux 要引入一门新的语言诞生的问题，因为 c 实在太老了，真正会的人只会越来越少，所以 rust 被合并进去了，可以当成是一种现代化尝试。并且你把 rust 换成任何一个语言照样会爆发类似这次的争吵。

这种就是典型的你行你上问题。。。不想多说

c/c++ 这么简单的东西...越来越少...
妈的, 我昨天看到一个笑话, 微软研究者说使用 AI 会降低人的批判能力. 这他妈的不是又当又立吗?
反正我倾向于人类走向 wall-e 语言的世界.
我昨天还被我妈怼, 写字的能力弱化了, 写通知的能力弱化了, 语文表达能力弱化了, 在她眼里我就是个渣渣...

世界真的进步了吗? 我狂笑三声

大概意思就是，我是个前端，要加个页面，需要使用后端的一个接口。
然后通知了后端一声，说我要用这个东西了。
然后后端来了一句，我不允许你来更改我的代码，我也不想我改这个接口的时候还要通知你。

那确实是有的啊，没人用而已
github.com/redox-os/kernel

单片机还在用着汇编和 C ，怎么都不可能淘汰，甚至有些还是用的 C89

那只是你是这么觉得，事实上之所以进入内核的是 rust 而不是 cpp 就是因为 cpp 实在太复杂了，而且很多特性没法禁用，会给 review 造成问题。并且会 cpp 的群体和 c 很重合，主力军都不小了，需要一点更新的东西和更年轻的人来参与到 Linux 中。

c 还算简单，c++简直太复杂了好不好

建议分裂出一个 Rinux 内核 /doge

搞新内核太难，就算 google 前几年搞的 fuchsia/zircon 都已经凉了

其实主要 c++ 编译器做了很多"看不见"的事情, 你可以看看 c++ 对象模型.
至于多态继承什么的, 其实我觉得很多时候, 可以看看 CRTP/静态多态 + SOLID 原则在 C++ 上的应用, 或者说用 Java 的写法写 c++.
我后来也喜欢 c 比较简单, 虽然干活累一点. 我有一段时间 c++真的为了偷懒都喜欢写一些可复用的模板, 以至于 visual studio 的 intellisense 直接没响应了. 特别是我用了一些 c14 之后的特性, 比如我把 function 的参数都做成模版类型推导. i9 的机器直接卡爆. 感觉 屌软 在全员使用 C＃ 之后, c++ 就被抛弃了... 所以各种 c++ draft 的开发都比较慢, 但还是比 gcc 快....

Rust 连单片机领悟都没混出像样点的东西，全面进 linux 别妄想了，后面可能会吧合并进去的几个 rust 东西直接移除，因为这样已经被污染内核了，造成跨平台移植困难

中小型公司的老板还是喜欢短平快, 你要 get 老板的 G 点. 复杂的东西, 还是自娱自乐, 没成熟之前不要用在工作上.

说实话，想要了解这次的冲突，起码要大概会点内核，明白大概的子系统，要很熟悉 rust ，并且看过 rust for linux 是怎么做抽象的和现在的项目进程才能说出点正常的评论。
不然就会犯以为现在 rust 重写了 Linux ，或者核心部分由 rust 编写了的错误。
实际上现在 rust 也就能写写驱动，做对 c 语言 api 的抽象，并且只抽象出来了非常小的一部分内核功能，这次的焦点 dma 的抽象都没有，离什么 rust 重写内核还差了十几年，而且 Linux 现在本身根本没有哪个部分是 rust 开发的。

C++11 、14 、17 、20 、23 、26
C89 、C95 、C99 、C11 、C17 、C23
标准都有这么多，还简单？而且 C 标准和 C++标准是独立的

支持。。

Linux 有太多 C 代码了，，就算用 Rust 写部分模块，，可 Rust 模块和 C API 之间的接口没法保证内存安全，，建议干脆完全用 Rust 写一个全新的 OS ，，彻底保证内存安全。。

你也可以看看 ATL 早期的库. 我其实觉得 ATL / WTL 这些算是 c++ 用得比较成熟的东西了. 包括 Don Box 发明的 COM 和面向接口编程, 真的是 c++ 集大成的天才设计. 我觉得微软最牛逼的贡献之一, 就是解决了大规模并行开发的范式.

复杂的是 C++ 支持的范式太多, 然后各种范式像 spaghetti 那样搅和在一起, 这个人是这个人的写法, 男个人是那个人的写法, 说白了, 我看你不顺眼.

Orz

别太理想化，rust 年初在 project goal 里把 rust for linux 定为代表项目，现在 project goal 里列出来的问题又解决了多少呢…大社区驱动的项目完全取决于贡献者的热情，比如 之于 async ，我几乎读过所有 active 的 RFC ，rust 的变化相对还是很慢的，任重而道远咯

AI 那么强，都说要替代程序员了。为什么不让 AI 把 Linux 内核重新用 rust 重写一遍

linus 为了稳定跟统一性，肯定不会让 rust 进入上游啊。

这就好比一个公司业务用 Java 的 ssm 框架跑的好好的，稳定十来年了，结果你一来，说什么这个框架太老了，不行，要换成最新的 golang 来跑。这是一样的道理。

firefox 整明白了吗？

Rust 写的新内核，是指 Redox?
还是指 API 兼容原 Linux 的 Rust 版 Linux 内核？

rust 的 内核当然是有的

github.com/asterinas/asterinas

Asterinas is a secure, fast, and general-purpose OS kernel, written in Rust and providing Linux-compatible ABI.

有一个 www.dragonos.org.cn/

有啥张口就来的，接触的几个 Rust 神教都说 Rust 安全，但是光语言安全并不能证明开发出来软件安全，某企业的网关用 RUST 开发的，效率很好，但是有缓慢的内存泄露。我本身也是写过这玩意的代码的，但是涉及到写高性能的一些代码的时候我还是得切回 C/C++
前段时间我还本地改过 wirefilter 换底层正则库用 hyperscan ，但是 hyperscan 还是得底层 C 库支持，我建议先把重量级底层库替换再继续

成熟是个定义，也许 Ruster 已经认为 Rust 成熟了。
技术政治原因没什么问题，不过 C 太老不觉得是被取代的理由，

多扯一句，rust 大规模进入内核是必然的吗？还是那句话，这个事情能带来什么肉眼可见的收益再说吧。

rust 还是先解决自己连全局变量都不好使的毛病再来说 system programming 吧

不是取代，是一直都有加入第二门稍微现代一点的语言到内核里建议，c++ for linux 的设想都十多年了，并且都有人写出 patchset 了，最后没被接受，最后不了了之了。
rust 所谓的内存安全其实不包含内存泄漏，而且现在的”内存泄漏“很大可能是是 glibc 分配器的问题，很多 rust 用 tokio 的程序换成 mimalloc 会好很多。并且所谓的安全其实反倒不是太重要，开发体验的提升才重要，毕竟 c 这个老古董，懂得都懂了，内核里现在都开始引入类似 go 里面 defer 的机制了。
并且这次吵起来中的人里就有维护 macbook 的那个 linux 发行版的人，因为那个内核里图形驱动就是 rust 写的，这个项目虽然不完善，现代的开发体验本身就是收益。
最后 rust 现在只是 kernel api 的抽象，最多只能用来写内核模块，短期内都不会出现 rust 写核心部件的情况。

从这帖子下的暴论就能看出有的人真的是张口就来。

接触的几个 Rust 神教都说 Rust 安全……但是有缓慢的内存泄露

经典「对于别人论点中不懂的名词望文生义，然后打虚空靶」，你知道 memory safety 是什么意思吗？你知道内存泄漏是 safe 的吗？维基的定义给你，这可不是你口中的「 Rust 信徒」信口开河瞎编的词语哦： en.wikipedia.org/wiki/Memory_safety

我本身也是写过这玩意的代码，但是涉及到写高性能的一些代码的时候我还是得切回 C/C++

所以为什么要切回呢？为了「高性能」？但你明明说 Rust 的缺点是「可能内存泄漏」啊？看不懂你的前后逻辑。

hyperscan 还是得底层 C 库支持，我建议先把重量级底层库替换再继续

孤例代表整体的谬论。rustls 替换 OpenSSL 、uutitls 替换 coreutils 算「重量级」吗？另外 Rust 本身标准库的正则性能就不低，我好奇为什么需要上 hyperscan ？

不信？数字说话，rust std 里的 regex 性能就是能和 hyperscan 打平手： github.com/rust-leipzig/regex-performance

rust 大规模进入内核是必然的吗？还是那句话，这个事情能带来什么肉眼可见的收益再说吧。

但现在连个「用 C 子系统的 Rust 接口定义」都不让进主线了，哪来的直接收益可以看呢？经典又要马跑又不准马吃草。

说到收益，Asahi Linux 用 Rust 编写的 Apple 设备驱动没有出现过重大内存安全问题算不算？

rust 还是先解决自己连全局变量都不好使的毛病

什么乱七八糟的，要么你已经五年以上没有用过 Rust 了，要么你根本没搞懂 Rust 中的全局变量怎么写。我用 Rust 从来没有遇到过全局变量不好使的问题。

太难了 一堆人在吹用 rust 的好处 但在我眼里它有许多致命的坏处 撰写成本过高 工作上不能快速更动并翘二朗腿的语言不是很适合搬砖 太占硬盘还有编译慢都很致命 私下用如果排除以上因素还外加一个语法糖很魔幻 语法糖并没有什么哲学大架构的意义 考虑的小细节也是太多

再补充一句，要是说「编译速度慢」「依赖 LLVM Backend 」「工具链复杂化」「与 C 开发者协调困难，拖慢开发进度」「严格类型系统鼓励过早抽象，造成重构优化困难」，我都算 Ta 骂到点子上了。

但有的人偏偏既不懂 Rust ，又不懂 Linux ，没看过 RIL 的仓库，还根本不知道这次事件的来龙去脉是什么、双方分别是谁，看几个 AI 翻译的生成文章就开始张口就来，属实贻笑大方了。

c 的内核安全成熟，为啥里要搞一坨 rust 出来？一直都没有个充分的理由。想推 rust 的是手里有锤子看什么都是钉子？

说明你根本没看懂我在说啥，你的反驳很符合《学会提问》里面的一些观点，看起来非常专业，但是你攻击的点不对。
我的观点“使用 RUST 开发出安全的内核，需要安全的语言+安全的开发”，我并不觉得语言安全就一定要大规模推广，恰恰相反，重点还得“安全的开发”。所以我并不是要说 rust 导致内存泄露，重点是安全的开发

解释一下为什么要切回 C/C++，因为需要对 Suricata 做二次开发，涉及到引入新协议和多模态匹配的开发。Suricata 的多模态匹配部分是 C ，协议解析器是 Rust 的

至于你说的 rust std 的 regex 性能和 hyperscan 打平手。。。我后续会看一下这个 bench 的内容，起码我一年前写的时候我测试的同时匹配 20000 条正则规则时，hyperscan 的多模态匹配效率高很多（和条件相关）

孤例代表整体的谬论，这个的反驳我认可，但是我所谓的替换是指当我要编写代码的时候第一反应是安装 Rust 版本的基础哭而不是旧版本

最后一点“经典又要马跑又不准马吃草。”，这有什么好奇怪的呢？什么事情不是得先做出来比当前优秀的成果才能推广的？真以为这世界非常友善？

嗯，我理解是引入现代的语言，C++这个我觉得没可能，毕竟现在 C++自己都在革自己的命。。。
你们的假设我在攻击 Rust 还有内存泄露，有没有可能我是想说即使用所谓安全的语言，不经过安全的开发，也会开发出来不安全的软件。

＃41

重点是安全的开发

所以你想表明什么，Rust 提供了一定安全，但因为没有把所有其他 Bug （包括内存泄漏，以及 C 语言的 Bug ）从根本上全部解决，所以引入的意义很小？

我明确一下我的观点：「目前，Rust 加入 Linux 是为了预防未来的新模块中引入新的内存安全问题」，至于已有的 bug ，当然要靠 C 开发者来修咯。

解释一下为什么要切回 C/C++，因为需要对 Suricata 做二次开发
我所谓的替换是指当我要编写代码的时候第一反应是安装 Rust 版本的基础哭而不是旧版本

这都是你自己的情况，我没法读心提前知道。Again ，直接说「 Rust 不适合我的场景」不就好了，没看懂这和你前面的举例有什么关系。

来来来，Arc<Mutex<[T, SIZE]>>的全局变量要怎么用零初始化？ C 的全局变量只要一行，rust 要几行？

我觉得你需要审视一下你对我观点的假设，我前面的观点都是“重点是安全的开发，而不是语言，人很重要“，所以建议直接 choose the hard way ，走自己的路。 而不是“Rust 没能解决所有问题，所以引入的意义很小”，涅槃谬误也太荒谬了。

至于你的观点，你说的“预防未来的新模块中引入新的内存安全问题“，所谓新的内存安全问题指什么，我很好奇，

你说“ Rust 不适合我的场景」”，当然可以这么说，我想表达的是，只有 Rust 成为最优选择的时候，Rust 语言才会有话语权，当然，这依然是纯观点，哈哈

Rust 大势所趋，但内核不是一个人开发的，贸然切换会丢失现有人力，举步维艰

多说一句，如果我回复的内容不清楚导致你理解错误我的观点，那我先道个歉，毕竟词不达意是一个巨大的缺点

＃44
首先，全局变量不能使用 Arc 初始化，因为它依赖原子计数器，而原子操作是平台定义的而且需要分配内存，请你回去重新学习一下。

强调一下，这不是语言的问题，相同的语义在 C 中也不可能实现，因为这就不是编译期静态初始化能完成的事。具体请读： users.rust-lang.org/t/what-prevents-arc-from-having-a-const-constructor/49532

另外，如果你试图编译 static ... = Arc::new ，编译器输出的报错会直接告诉你使用 LazyLock 即可，这也是一个解决方案。

然后，[T, SIZE] 这个语法我没查到，我猜你想说 [T; SIZE]？实现在这里：

static GLOBAL: Mutex<[i32; 1024]> = Mutex::new([0; 1024]);

还有别的问题吗？

rust 不能就不是语言的问题了。怪不得要被 linux 踢出来呢，果味十足，教人编程啊

来来来，还没完，T 是个 struct 的时候，你要几行啊？是不是还要来个 copy trait 啊？这要几行啊？

对了，原子变量不能静态分配是吧？那我这 DEFINE_SPINLOCK() 是干啥的？你写过几行内核啊？

这边建议 linux 内核和三星的手机一样
一个猎户座版本，一个高通版本

我支持 C ，效率和灵活性加起来要比单纯的安全更重要一点。因为写 C 的程序员的初衷也不会是不安全。

相较于裸指针来说，Rc 都是消耗，更何况 Arc 。全世界这么多 linux 设备，为了计算 Rc 和 Arc 要多消耗多少能源呀。🤪

＃50

刚打了一大段字被 V2EX 吞了，比较坏心情。我说重点吧。

怪不得要被 linux 踢出来呢，果味十足，教人编程啊

鄙人不才，翻过两页 Rust 教程，教人写全局变量不成问题。至于第一句，我认为你完全在撒泼、无理取闹了。不知道你在对谁说话，我又不是 RIL team member 。

T 是个 struct 的时候，你要几行啊

当然是一行。

是不是还要来个 copy trait 啊？这要几行啊？

咄咄逼人的语气，不明白你想说什么。首先，如果要做公平的比较，显然 C 的所有 struct 都是（在 Rust 语义上） Copy 的吧。如果禁止 Rust struct 实现 Copy ，那在 C 中根本找不到对应的语法特性了，比较没有意义。

但尽管如此，丢代码，这段代码还实现了动态确定每个元素赋值的需求（而不像 C 只能赋常数）： play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c180d3fc345e865024298088c079ad3e

原子变量不能静态分配是吧？那我这 DEFINE_SPINLOCK() 是干啥的？

……什么乱七八糟的。旋转锁对应的是 Mutex ，我说的是「 Arc 不能静态分配」。

你写过几行内核啊？

移植重写过 NPU 驱动： github.com/w568w/alarm_repo/blob/main/linux-orangepi-3b-dev/0003-rknpu-add-rknpu-driver.patch

为 SBC 移植 u-boot： github.com/w568w/u-boot-orangepi-3b

＃53 fix：上面那段代码的正确链接应该是 play.rust-lang.org/?version=beta&mode=debug&edition=2021&gist=978f5add73e7fa241821b926ec0f8efc ，都躺在剪贴板里，发错了。

所以为什么这么咄咄逼人呢，为什么我提代码你就要开始扣帽子 + 需求加码呢？

我很好奇「不能在一行内声明一个没有实现 Copy trait 的 struct 成员的静态预初始化数组」，就是你所说的「 Rust 连全局变量都不好使」？这样的需求你在 C 中甚至不可能碰到（因为 C 里所有 struct 都是 "Copy" 的）。

＃28 你别说你还真别说，确实不远了。
很多项目的开发成本来源于人工，用 AI 以后对人工需求下降，很多不可能经济地实现的事情现在已经变成可能了。
前几天刚给一个开源项目发了 2 个 PR ，半 AI 半人工的优化，找到热点以后让 AI 做针对性优化，性能大幅提升。
这种本来可能要花几个小时甚至几天才能做好的事情，现在一个晚上就能写完了。
我只要花时间开 profiling 找到哪个函数最慢，然后告诉 AI 我要优化这段代码，AI 基本就能把事情干完了。

有啊。Redox 了解一下。可惜曲高和寡。

主要是开发和使用都费劲，rust 现在高层还可以，但是底层（内核）部分还是少
而且一堆驱动和文件系统都费劲，这玩意需要堆人力，或者把内核模块化，然后 ffi 调用现有接口。
然后是性能，你这要是比人力优化的还慢，那就只能是玩具了。

开发相对好说，稳定需要时间检验。

我个人对开源项目的看法是，任何付诸行动而不是停留在口头上的行为都值得称赞(比如 RIIR)，另外不就是因为拥抱变化才有了如今的百花齐放的开源项目么？

回归到问题本身，内核要不要引入第二种语言，我觉得只要有人愿意做，能控制质量和范围，逐步推进，多几种语言都没事，反而能吸引更多的贡献者

至于 Rust 和 C 或者别的语言之争，实在是没啥意思，不是踩低别人就能抬高自己，反之亦然，纯属个人或小部分人的口舌之快，不知道为啥有人这么执着，就像有的人对 if err != nil 深恶痛绝，有的人对 python/perl 里面的各种奇技淫巧爱不释手

zig 也想进入内核，汇编觉得用 c,rust 都不够好，go 觉得我也可以试试，Crystal 如果 go 可以我也行。怎么办？