邮件原文
知乎翻译
翻译搬运：

我曾抱有希望，并试图看看这个漫长的讨论是否能产生一些建设性的结果，但现在看来，事情似乎在倒退（或者至少没有进展）。
事实是，你反对的那个拉取请求根本没有触及 DMA 层。
它只是另一个使用 DMA 层的用户，位于完全独立的子目录中，没有以任何方式改变你维护的代码。
我感到不安的是，你竟然在抱怨新用户使用你的代码，然后还不断提出这些完全站不住脚的论点。
老实说，你一直在做的，基本上就是在说“作为 DMA 维护者，我控制 DMA 代码的用途”。
而这根本不是这样运作的。
接下来是什么？说某些驱动程序不能使用 DMA ，因为你不喜欢那个设备，而作为 DMA 维护者，你控制谁可以使用 DMA 代码？
这正是你试图对 Rust 代码做的事情。
说你不同意 Rust——这没问题，没有人要求你编写或阅读 Rust 代码。
但随后你采取了一种立场，认为 Rust 代码甚至不能使用或与你维护的代码交互。
所以让我非常明确地说：如果你作为维护者认为你可以控制谁或什么可以使用你的代码，你错了。
我在技术上尊重你，也喜欢与你合作。
不，我不是在寻找应声虫，我喜欢你指出我的错误。我有时会说一些愚蠢的话，需要有敢于站出来告诉我我错了的人。
但现在，我要指出你的错误。
所以这封邮件不是关于某些“Rust 政策”。这封邮件是关于一个更大的问题：作为维护者，你负责你的代码，没错——但你并不负责谁使用最终结果以及如何使用。
你不必喜欢 Rust 。你也不必关心它。这一点从一开始就很清楚，没有人被迫突然学习一门新语言，那些只想在 C 语言方面工作的人完全可以继续这样做。
所以回到你声明的核心：
“该文档声称没有任何子系统被强制要求采用 Rust”
这一点非常正确。
你没有被强制要求接受任何 Rust 代码，或关心 DMA 代码中的任何 Rust 代码。你可以忽略它。
但“忽略 Rust 方面”也自动意味着你在 Rust 方面没有任何发言权。
你不能两者兼得。你不能说“我不想与 Rust 有任何关系”，然后在下一句话中说“这意味着我将忽略的 Rust 代码不能使用我维护的 C 接口”。
想要参与 Rust 方面的维护者可以参与其中，通过参与，他们将对其 Rust 绑定的外观有一定的发言权。他们基本上也成为 Rust 接口的维护者。
但选择“我不想处理 Rust”的维护者显然也不必费心处理 Rust 绑定——但因此他们在 Rust 方面也没有任何发言权。
所以当你更改 C 接口时，Rust 方面的人将不得不处理后果，并修复 Rust 绑定。这就是这里的承诺：对于那些不想处理 Rust 问题的 C 开发者来说，有一个“保护墙”，承诺他们不必处理 Rust 。
但这“保护墙”基本上是双向的。如果你不想处理 Rust 代码，你在 Rust 代码上就没有发言权。
换句话说：“没有人被迫处理 Rust”并不意味着“每个人都允许否决任何 Rust 代码”。
明白了吗？
不，我实际上并不认为这需要如此黑白分明。我上面用非常黑白分明的术语陈述了这一点（“成为 Rust 绑定的维护者”与“完全不想处理 Rust”），但在许多情况下，我怀疑这条线会不那么严格，子系统维护者可能知道 Rust 绑定，并愿意与 Rust 方面合作，但可能不会非常积极地参与。
所以这真的不必是一个“全有或全无”的情况。

个人认为，linus 找的角度还是可以的，比较理智。

linus 虽然前段时间因为封杀俄罗斯的事情，有点败人品。
不过人品不说，对于项目的技术控制还是不错的。 天天下面一堆人抖机灵，拍脑壳，都要硬生生的控制住，让项目不乱套。还是牛逼！

后面的故事我已经想好了。
下一集：Christoph Hellwig 不满 linus ，fuck rust ，对 dma api 进行 breaking change ，煽动起社区厌恶 rust 的人一起来挑战 linus 权威。
linus 随之反抗，将 Christoph Hellwig 从 dma mapping helpers 除名。
借此一战 Hellwig 成功吸引到一批追随者，随之对内核进行 fork ，剔除了 rust 。
历史上称此次事件为<<<RUST, F* You! , Linux fork PANIC!!!>>>
（狗头）

🤔等真有人走了才开始发觉大事不妙了?

所以如果最后 DMA 子系统 breaking change 了，坏掉的 Rust binding 谁来修呢

＃4 大概是就这样坏着，或者导致 rust 代码编译/链接失败，毕竟内核内部不保证 api 稳定

ntfs-3g 的维护者其实也有类似的问题，别人看到 bug 然后提交了补丁，维护者不接受，推行自己另外的 ntfs 相关的付费软件

Rust 自己先把路人缘给败光了啊 说句实在的不少人是觉得这个玩意是个邪教，这个事件哪怕 rust 侧更占理，不少人也是觉得不给 mr 合入是正确的选择

哥们你这脑洞，书无店砸（狗头

不得不书说，我也算是读过一些 mailing list ，但是至今搞不懂这个邮件列表怎么直接找别人的回复。。。

＃2
好希望看热闹啊。。。。

Russia 和 Rust 都是 Ru 开头（逃

当然是写 dma 抽象的人来修，而且 rust 侧的很多 wrapper 本身都不是太复杂，就比如这次抽象的 dma_alloc_attrs 本身逻辑简单，就是可以附加不同属性的分配 dma 内存，就算由 break 了估计最多一小时就能完事。

一直偏执的阻止 rust 的使用何尝又不是一种邪教呢。

难道没有沟通吗，内核开发？这些人是不是太老了。

＃13 正常项目是不会引入第二语言的，只会带来维护难度

这一次不管是 Linus 还是 Christoph 表现都令人失望。
仇恨、反对、阻挠 Rust 的情绪已经超过了合理的理由，变成了一种纯粹的偏执。R4L 的维护者反复提到自己会负责维护 Rust 层，哪怕是这样，Christoph 还是拒绝合并。
Linux 内核开发后继无人也不是新话题了，包括这个可读性极差的邮件列表在内，只能说 LINUX 内核就是一个抵制变化和年轻血液的老登社区。

不能理解，c++不能进 rust 却让进。
哪个更亲近 c 还用说吗？

当然是 zig 最亲(233)

linus 的观点是，对 c 来说 cpp 没有从根本解决内存等问题，甚至引入了更多不必要的复杂性。

R4L 的维护者改用 C 是更妥当的解决方案，看不出一定非要 RUST 的理由

linus 虽然前段时间因为封杀俄罗斯的事情，有点败人品。

人在江湖，在那个位置，总会有很多牵扯，没必要用平民事不关己看客的身份去吹毛求疵大佬们的这些无奈之举

这一次不管是 Linus 还是 Christoph 表现都令人失望。

所以只要观点正确，随便去社交网络发小作文是好事情、linus 应该大力支持并且也跟着去发作文大力支持？
但凡仇恨、反对、阻挠 Rust ，linus 当初直接就拒绝 rust 了，还用得着给你演这么多？

R4L 的维护者改用 C 是更妥当的解决方案，看不出一定非要 RUST 的理由

虽然推进 Rust 主要原因是内存安全，但我个人觉得更重要的是，C 越来越后继无人了

＃17 c 和 c++只是部份相近，但几乎完全是两种工程风格，实际工程中并不相近。而且 c++背后的隐含的小动作太多了，即使是老鸟也要谨小慎微，内核这种吹毛求疵的场景、用 c++一不小心就搞出大事、还不如 c 更加安全可控。而 c++相比于 c 的便利几乎不值一提，尤其是，c++并没有解决 rust 能够解决的内存安全问题。

反正等着这群老 B 死就行了,反正内核开发几乎没有新血.

反正等着这群老 B 死就行了,反正内核开发几乎没有新血.

你行你上，你去搞个能直接替代 linux 都可以。如果现在的 Rust 人能直接搞个新的我也是支持，但问题是目前也没哪个 Rust 团队能搞得定这么重要庞大的基础设施、而且最关键的是已有的社区依赖，全世界多少设备在上面跑着呢，不是过家家说换就换了。

前人栽树，后人纳凉，应该懂得感恩，而不是一边纳凉，一边骂娘，这种骂娘并不能显得自己高明，更不能显得自己高尚。

＃22
内核代码，一切问题都该摆在明面上。
rust 自动内存管理不是该更令人担忧吗？
linux 程序员，写 c 的都是老鸟，如果有 c++，也该是老鸟程序员，新手程序员就不应该提交内核代码。

你可以去看看 rust for linux 的代码，rust 的抽象程度也就是 better c 的程度，就比如栈上指针的 box ，rust for linux 分成了三个类型，分别是 kmalloc 的 KBox ，kvmalloc 的 KVBox 和 vmalloc 的 VBox 。
你要说的 raii 的话，rust 也有一堆办法可以让一个类型避免超出作用域被析构，甚至直接调用 kmalloc 系列用和 c 一样的原始指针也可以。
我就这么说把，rust 的代码就算内核里的 c 开发者没学过 rust 也能完全搞明白代码逻辑，根本没有 cpp 里那么多 implicit 的东西，也没有 cpp 那么多的黑魔法，起码 review 的时候很直观。

打错了，不是栈上指针，是分配内存所得到的指针。

rust 自动内存管理不是该更令人担忧吗？

rust 的和自带 runtime 和 gc 的自动内存管理完全是两码事；如果跟 c++比，rust 更内存安全而且也不像 c++那么复杂没那么多隐藏的黑魔法，现在和以后都应该不会有比 c++更复杂了。

c++老鸟就更不要提了，最该反对的就是那些所谓的 c++老鸟搞出一大坨 c++11 之后的所谓现代 c++代码，老鸟是 happy 了，让后来人怎么玩？语言本身比要做的东西还复杂，整天把心智浪费在语法语义的讨论上，隔三差五一个 issue 讨论这个语法/语义这样用有没有问题？
现代 c++最大的毛病就是十年不出门，出门也是恶心人。

linus 拒绝 c++进内核不能更赞了。

＃28
不管是 c 还是 c++都没有 runtime 这种东西
即使一个语言内部实现的内存引用计数，我也不认为这种东西该存在内核里边。
linus 拒绝 c++进内核，是担心语言的复杂性导致 bug 难于发现; 换成 rust,同样的问题就没有了吗？所谓内存安全增加的语言实现会令 bug 隐藏更深。
所以我的观点是有 c 就够了，保持简洁，不要增加阅读者的心智负担，bug 就出在人们看着难于理解的地方。

1. rust 并不使用引用计数。内存管理依赖的是所有权系统，它是显式且编译期检查的；
2. 如果你觉得 C 和 C++没有 runtime ，那么 Rust 也没有；

3. “换成 rust ，同样的问题就没有了吗？”。工程上的问题并不是“绝对没有 bug”，“绝对可靠”才行，而是在成本、风险和收益之间进行取舍。C++成本、风险都很高，收益微乎其微，而 Rust 则不同。

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

   我不觉得引用计数是个问题，搜了下，引用计数在内核好像是挺常见的：
   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 可以忽略，因为复杂性不大而且并没有因为复杂而带来更多副作用、而是用这点复杂去更大程度上解决内存安全等问题，你说的点是不太成立的

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

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

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

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

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

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

rust 是支持引用计数的，而且非常常见，如 Rc (非线程安全引用计数)、Arc (线程安全引用计数)

＃32 谷歌好像还出了个 Carbon ，生产上投入多吗

＃32 我硬生生把你所有的回复看完了，👍，折服你的语言表达和逻辑思路

这点我是知道的，但这只是标准库里实现的智能指针，可以不用……
仅从语言本身来看，它的内存管理不依赖引用计数。有些语言的内存管理不能不使用引用计数，比如 Objective-C 、Python 等。
然后，哪怕是 C 、C++没有引用计数，项目中仍然可以自己实现这样的内存管理机制。

他的意思可能是指 C++没有，觉得换成 Rust 一定会有。这种说法是不成立的，我想说的只是这一点。

这个语言目前还没达到“用于评估的最小可行产品”阶段，投入生产得是很久以后的事情了