Linux 中的 Rust 内核不再处于实验阶段

内核中的Rust已不再是实验性技术——它已成为内核的核心组成部分

 💬 438 条评论 |  rust/linux | 

在年度维护者峰会上，Rust实验议题刚刚完成讨论。与会开发者达成共识：内核中的Rust已不再是实验性技术——它已成为内核的核心组成部分，并将长期存在。因此“实验性”标签即将移除。在此向整个Linux Rust团队致以祝贺。

（详情请关注我们对维护者峰会的后续报道。）

本文文字及图片出自 The (successful) end of the kernel Rust experiment

共有 438 条讨论

  1. 听到这个消息真是太好了。感觉Rust支持在过去两年里取得了长足进步，现在几乎无需冗余代码就能实现功能完善的Rust内核模块。

    移除*“experimental”*标签无疑是值得庆祝的里程碑。

    我期待各发行版默认启用Rust支持的内核。对我而言，这才是真正的不可逆转点——当Rust普及到无法再回归纯C语言的Linux时代。

    回复

    1. 已有部分发行版实现这一目标。据我所知，NixOS和Arch都启用了用Rust编写的QR码内核崩溃界面。虽然它们属于尖端发行版，但我知道一些传统发行版也启用了该功能(我记得Fedora有？但不确定)。

      回复

    2. > 对我而言，这才是真正的不可逆转点——当Rust普及到无处不在时，C语言主导的Linux时代将一去不返。

      为何Rust非要取代C语言？这让人强烈联想到《他们活着》的氛围。

      光看“Rust”这个名字就说明了一切：它通过氧化有用的铁并将其撕碎来蔓延，随后又带着自身催化剂(热量和水分)继续扩散。这里的热量象征着“所有C语言都该腐朽”的偏执态度，而水分则来自那些栖身星辰之上的极客们流下的眼泪。

      回复

      1. 因为终有一日编程技术必须超越1970年代的水平，终有一日我们必须停止引入导致恐怖漏洞的新内存安全缺陷。至于内核代码，我们没有奢侈的余地去重新编译所有内容，用垃圾回收机制来敷衍C语言无法治愈的缺陷。

        回复

        1. Unix/C开发者在1970年代选择自主编写内核，而非入侵现有系统。

          回复

          1. 若Rust无法为Linux内核创造价值，它绝不可能走出实验阶段。

            Rust并非入侵部落，它只是工具。

            回复

            1. Rust确实具备模块化与模式匹配等优秀特性。但整个开发过程涉及大量Rust社区成员，其中知名开发者Hector Martin(其虚拟身份Asahi Lina是女性虚拟主播，他对此却莫名感到尴尬)曾对他人实施骚扰。连Linus Torvalds都曾公开谴责Hector Martin。

              https://lkml.org/lkml/2025/2/6/1292

              > 2025年2月6日周四 01:19，赫克托·马丁 <marcan@marcan.st> 写道：

              > > 若社交媒体羞辱无效，请告诉我还有什么方法，我实在束手无策。

              > 何不接受问题可能出在你身上的事实？

              > 你自以为高人一等。但现有机制运转良好。

              > 它存在缺陷，但缺陷本就是现实。世间本无完美。

              > 不过我必须说，社交媒体上的围攻让我彻底不想参与你的方案。

              > 因为若内核开发模式存在问题，社交媒体绝非解方——正如它绝非政治问题的解方。

              > 技术补丁和讨论才重要。社交媒体围攻——谢了，不干。

              > 林纳斯

              https://archive.md/uLiWX

              https://archive.md/rESxe

              回复

            2. > Rust不是入侵部落

              从事开源工作的人常对代码抱有部落意识，会阻挠那些虽好却威胁其社区地位的创意。本质上与办公室政治无异，只不过争夺的不是金钱而是个人尊严。

              回复

              1. 我敢肯定，若向Rust项目提交PR提议用Ada/SPARK重写部分代码，定会受到热烈欢迎。

                回复

                1. 若有人向我的项目提交此类PR，并能阐明其带来的显著优势——即便需权衡复杂度/可维护性等代价——我将欣喜于有人如此用心改进我的软件。

                  回复

                2. 为什么？这取决于你想替换什么，但Rust项目长期以来一直使用其他语言编写的工具。Python在构建工具领域应用广泛，bors-ng采用Elixir编写，llvm使用C语言实现…根据https://github.com/Rust-GCC/gccrs所述，gcc-rs同样不包含大量Rust代码，其核心完全由其他语言构成。

                  根本上，若工具优秀且能带来效益，何乐而不为？若你突然抛出用Ada/SPARK编写的代码，必然会遭遇可维护性质疑——这很合理，正如当年Rust引入Linux内核时同样面临可维护性担忧。但这些疑虑最终被决策群体认可，经权衡利弊后认定净收益为正。

                  回复

            3. “创造价值”的论点可以套用在任何事物上。现代软件政治与基金会赞助压力如此复杂，这个论点甚至可能根本不成立。

              此案例或许成立，但你肯定见过企业臃肿化渗透到“开源”项目的先例。

              回复

              1. > 现代软件政治与基金会赞助压力错综复杂，此论点未必成立。

                未必，也未必不成立。据我与Linux内核社区的互动经验，其运作模式与典型“现代软件政治”截然不同——至少差异显著到足以让我断言其具有特殊性。

                若真有哪个社区能基于纯技术考量做出决策而不受政治压力影响，那必然是Linux内核社区。当然，任何个人或社区都非完美，但除非有确凿证据表明Linux团队被迫接纳Rust进入内核，否则我至少不会轻信此类论调。

                回复

            4. > 若Rust对Linux内核毫无价值，它绝不可能走出实验阶段。

              这属于“诉诸权威”谬误。

              回复

              1. 指出某项技术在其诞生地经过迭代后被采纳，如今竟成了谬误，真是奇妙。

                回复

            5. 若Rust团队真有创造力，早该编写自己的内核了。他们总在喊“重写这个，重写那个”。

              C语言定有激发创造力的独特之处。

              回复

          2. 他们同样创造了自己的语言(C)。正因当时的语言无法满足需求，他们才发明了新语言。你的论点刻意忽略历史中不便提及的部分，只突出那些看似支持己见的片段。

            回复

          3. “入侵”

            你选择的措辞确实有助于推进讨论。

            回复

          4. 内核才是核心价值所在，而非编写内核的语言本身

            回复

      2. 我记得林纳斯曾直接回应过这个问题。建议你仔细阅读他的邮件。

        归根结底，技术会不断演进，你或任何人都无法仅凭某些无稽之谈(非技术性理由)就阻止这种发展。

        回复

        1. 他在同一封邮件中关于Rust还提到：

          没人被迫突然学习新语言，纯粹想在C语言领域工作的开发者完全可以继续这样做。

          因此任何宣称Rust将彻底取代C语言、导致C在内核中消失甚至被禁用的论调，都与林纳斯的原意不符。

          https://lkml.org/lkml/2025/2/20/2066

          回复

      3. 纠结于名称问题会使你的整个提问和论点变得主观化，无法在建设性讨论中发挥作用。

        回复

        1. 总体而言，Rust拥护者似乎希望用便捷性与现代性取代C语言的优势——后者能以更强的控制力、更明确的意图实现相同功能，并获得更优结果。

          Rust的约束性较弱。这对应用程序尚可接受，但内核是所有Linux用户的底层支撑。

          Rust支持者贬低C语言，只因它不具备Rust的行为特性。

          为何内核必须具备Rust的行为特性？

          回复

          1. > Rust支持者贬低C语言

            不，长达五十余年难以避免的内存损坏错误，对C语言的贬损程度远超任何其他语言使用者。

            回复

            1. 我认为C语言根本不该被贬低。就像我偏爱星形螺丝，但这不代表十字螺丝是糟糕的设计——它们简单而高效。虽然我无法想象任何需要十字螺丝的场景，但历史中星形螺丝尚未问世，当时选择十字螺丝绝非错误。时代在变。

              回复

  2. 历经Linux内核对Rust语言的重重阻力，它终于正式入驻。向Linux Rust团队致敬！

    回复

    1. 难道不是有个维护者对Rust相关内容的草率拒绝，导致朝日项目陷入混乱吗？我虽没密切关注进展，但记得那场闹剧堪称经典的Linux内核百老汇剧场。我甚至怀疑那是否成了朝日项目的首块多米诺骨牌，现在真说不清这个项目是否还存活着。

      回复

      1. 据我所记，争议并非Rust与C之争，而是源于补丁质量问题，以及不该强迫他人接受某些方案。

        Linux内核团队总爱强硬抵制，若被逼得太紧，这种做法会伤透人心。

        赫克托似乎删除了他的Mastodon账号，无法查证他确切的发言内容。

        哦，相关标签页我还在。讨论的是代码质量问题：https://news.ycombinator.com/item?id=43043312

        回复

        1. 那只是庞大讨论串中的一条消息，绝非仅涉及代码质量。

          回复

          1. 没错，这就是通往兔子洞的入口，建议读者自行挖掘隧道。

            我记得当时关注过那段紧张交锋。确实存在其他关于实现方式的讨论，但读完后我始终将“代码质量”视为核心议题。

            在高风险的软件开发环境中，个人自尊往往高涨。当观点激烈碰撞且无人退让时，火花便会迸发。若忽视这种预警信号，终将引发冲突。

            若我理解有误，乐于听取合理解释并欣然修正。

            这正是当前发生的情形。二十余年来我目睹过两三次类似事件，最著名的当属CPU调度器之争——若我没记错，同样围绕BFS算法展开。

            回复

          1. 谢谢！我也来编辑补充。

            编辑：不行，太晚了，来不及了。

            回复

          1. 背景说明：我对Rust持怀疑态度，且已厌倦Rust布道小队和“用Rust重写”运动。

            —

            是的，我记得那条消息。

            别忘了marcan说过的话[0][1]。

            简而言之，某开发者不愿让C代码库被Rust代码污染——这我能理解；随后Rust团队表示可维护该部分代码，避免给他添麻烦(值得称赞)；结果开发者怒斥对方滚出“他的”领地(这点我虽理解但不认同，换作我会采取不同做法)。

            归根结底还是代码质量问题。相较于整个代码库，Rust只是个幼苗，老开发者心生倦怠实属正常。我们可以永远讨论行为准则，但人终究是人，不可能把一切都标准化。

            至于marcan的行为，在我看来同样不可取。因为这不健康。诚然LKML环境确实不健康，但这恰恰是“理直气壮时仍可能犯错”的典型例证。

            我参与的另一个讨论组也存在类似摩擦，正确做法是在疲惫濒临崩溃时暂离火线，去感受草木的温度——而非像燃烧的火炬般在易燃人群间穿梭。

            尤其在环境欠佳时，更应努力成为更好的榜样。这虽是最艰难之事，却也是最正确的道路。

            [0]: https://web.archive.org/web/20250205004552mp_/https://lwn.ne…

            [1]: https://lkml.org/lkml/2025/2/6/404

            回复

            1. 一种观点认为，Rust似乎是通过骚扰和压力被强行引入Linux内核的。而非通过谨慎、有机且友好的方式引入Rust，同时妥善处理任何重大异议。例如：将不稳定版Rust的相关特性迁移至稳定版；确保第二个编译器(如gccrs，Linux内核使用gcc进行C语言编译)完全运行；确认规范文件(由Ferrous Systems捐赠的规范可能存在重大问题)；或优先考虑内核而非Rust。

              倘若我曾热衷Rust，并想探索将其纳入Linux内核的可行性[0]，我大概会将注意力转向gccrs。

              更令人费解的是，rustc阵营(基于LLVM的唯一主流Rust编译器)竟公开对gccrs(针对gcc的Rust编译器开发中)表现出敌意。

              这令人感觉更像是企业收购行为，而非以良善技术为核心的协作。

              资金问题同样不容忽视，Rust基金会将筹款作为重要工作重点，正如其前身Mozilla/Firefox团队过去和现在都高度关注筹款活动。此外，一些重要的Rust支持者——包括在Hacker News上——公开宣称软件与政治本质上是相互交织的。

              [0]：同时不必将Rust引入内核作为硬性目标，因为可能存在发现Rust并不适配的情况；届时可针对适配问题进行改进，或许日后就能让Rust完美契合。

              回复

    2. https://www.phoronix.com/news/Alex-Gaynor-Rust-Maintainer

          << 亚历克斯·盖诺近日宣布正式卸任Rust for Linux内核代码维护者职务，相关移除补丁现已排队待合并至Linux 6.19版本。作为最早尝试将Rust代码应用于Linux内核模块的开发者之一，盖诺因时间不足已逐渐淡出Rust内核开发工作，此次正式卸任Rust代码的联合维护者职务。继韦德森·阿尔梅达·菲略去年卸任Rust联合维护者后，Rust for Linux项目负责人米格尔·奥赫达现成为该代码唯一官方维护者，另有数名Rust代码审阅者参与维护。>>
      回复

      2. “耶！我们把Rust搬进内核啦！_ 好啦，现在代码交给你了！拜拜！”

        回复

  3. 移除“实验性”标签是否意味着所有维护者现在必须保证不破坏Rust代码？

    回复

    1. 是啊，我一直在想电影里那个愤怒的胡子大叔。他肯定会非常生气。

      回复

      1. 我没跟上Linux/Rust的剧情，缺了些背景。哪个家伙？

        回复

      1. 这是Linux内核。用户空间想做什么都行。

        回复

      2. GNOME等项目正越来越多地采用Rust语言。

        回复

    3. 维护者没有义务保证不破坏Linux的任何部分，除了用户空间API之外，内核中不存在稳定的API

      回复

      1. 他们的意思是：Linux内核长期遵循“每次提交都保持整个内核可编译”的政策，因此任何修改内部API的提交，都必须修复所有使用该内部API的位置。

        当内核中引入Rust时处于实验阶段，为避免给不懂Rust的程序员设置障碍，这条规则曾有所放宽，使实验期间相关工作能不受阻碍地推进。换言之，在Rust维护者修复C代码中变更的API使用场景期间，允许Rust代码暂时处于不可用状态。

        回复

        1. 那么这是否意味着C开发者需要学习Rust，或与Rust开发团队加强协作？

          回复

          1. 实际操作中，建议将Rust纳入本地构建测试环境。但学习Rust的必要性与掌握Perl或配置脚本原理并无本质区别。

            只要能及时发现代码故障，即可快速掌握基础知识(若问题简单)或寻求帮助。

            回复

          2. 需掌握足够的Rust知识以理解跨语言影响，包括所有`unsafe`行为(…因为你需要与C语言交互)。

            确实如此。

            回复

          3. 取决于变更内容。

            若完全替换 API 则必然如此。

            但多数变更(如函数或结构体添加参数)基本无需学习新知识。

            Rust 与 C 语言亦有相似之处，多数代码可采用类似 C 的风格编写。

            回复

      2. 据我所知，存在这样一种预期：若对内核API进行破坏性变更，则需修复调用这些API的代码。这正是争议所在——若维护者不懂Rust，如何修复API的Rust用户？

        Linux版Rust团队提出，至少在实验阶段将负责修复此类变更。我猜这种安排的长期方案将在现在讨论。

        回复

  4. 这是否意味着所有Linux支持而Rust不支持的架构都直接被弃用？

    回复

    1. 并非如此。Rust已在内核驱动子系统中应用。核心Linux组件因你提到的限制尚不能用Rust编写，但新驱动程序可以用Rust实现

      回复

      1. https://lwn.net/Articles/1045363/

        > Rust 因被认为可能影响对旧架构的持续支持而引发担忧，但其实它支持内核约 20 种架构中的 14 种，例外的是 Alpha、Nios II、OpenRISC、PARISC 和 SuperH。

        回复

      2. 为验证此结论，我从https://doc.rust-lang.org/nightly/rustc/platform-support.htm… 获取Rust支持的平台列表，并从https://docs.kernel.org/arch/index.html获取Linux支持的平台列表，经过整理使两者可直接比对后，将其导入这个Python脚本：

          linux = { “alpha”, “arc”, “arm”, “aarch64”, ‘csky’, “hexagon”,
    “loongarch”, “m68k”, “microblaze”, “mips”, ‘mips64’, “nios2”,
    “openrisc”, “parisc”, “powerpc”, ‘powerpc64’, “riscv”,
    “s390”, “s390x”, “sh”, “sparc”, “sparc64”, ‘x86’, “x86_64”,
    “xtensa” }  
  
rust = { “arm”, “aarch64”, “amdcgn”, “avr”, ‘bpfeb’, “bpfel”,
    “csky”, “hexagon”, “x86”, “x86_64”, ‘loongarch’, “m68k”,
    “mips”, “mips64”, “msp430”, “nvptx”, ‘powerpc’, “powerpc64”,
    “riscv”, “s390x”, “sparc”, “sparc64”, ‘wasm32’, “wasm64”,
    “xtensa” }
  
  print(f“两者兼有: {linux.intersection(rust)}”)
  print(f“Linux但非Rust: {linux.difference(rust)}”)
  print(f“Rust但非Linux: {rust.difference(linux)}”)

        输出结果：

        两者皆有：{‘aarch64’, ‘xtensa’, ‘sparc’, ‘m68k’, ‘mips64’, ‘sparc64’, ‘csky’, ‘riscv’, ‘powerpc64’, ‘s390x’, ‘x86’, ‘powerpc’, ‘loongarch’, ‘mips’, ‘hexagon’, ‘arm’, ‘x86_64’}

        Linux，但不是 Rust：{‘nios2’, ‘microblaze’, ‘arc’, ‘openrisc’, ‘parisc’, ‘s390’, ‘alpha’, ‘sh’}

        Rust支持但Linux不支持：{‘avr’, ‘bpfel’, ‘amdcgn’, ‘wasm32’, ‘msp430’, ‘bpfeb’, ‘nvptx’, ‘wasm64’}

        个人而言，我从未使用过“Linux支持但Rust不支持”列表中的设备，不过曾在某处近距离看过展示的DEC Alpha，也认识有人曾拥有过世嘉Dreamcast(sh)。

        回复

      3. 更具体地说，哪些设备会有人在新内核上使用？

        回复

      4. 有人抱怨68k架构不被支持是个问题

        回复

        1. m68k Linux在Rust中是受支持的，甚至在LLVM后端中也是如此。

          Rust还拥有基于GCC的实验性代码生成后端(基于libgccjit库，但并非作为即时编译器使用)。

          因此既无LLVM也无近期GCC的平台就完蛋了。

          回复

          1. 没有GCC的平台究竟怎么编译Linux？

            另外我认为GCC后端尚不完整。core库能编译，但Rust的std库无法编译。

            回复

            1. 没有近期版本的GCC同样无法使用。

              没有近期版本的GCC和完全没有GCC是两回事。某些架构可能仍使用旧版GCC，但已不再支持C11、C23等较新C语言规范。

              回复

            2. 我不认为Linux版Rust使用std库。虽然不清楚GCC/Rust项目能编译多少Linux版Rust代码，但若真能“全部编译”，想必早有消息传出。

              回复

  5. 欣闻此讯。我们应当拥抱新事物。

    回复

        1. 那么——目前内核中实际用Rust编写的代码有哪些？

          回复

  7. 那其中目前有哪些是用Rust编写的？

    回复

      1. 理所当然，这可能是回报率最高的地方

        回复

        1. 我不明白为什么。处理硬件时你必须频繁使用unsafe。与C语言(内核其余部分)交互时也必须使用unsafe。

          在我看来，这种场景下采用Rust的理由存在缺陷。

          回复

  8. 内核中使用Rust是自我实现的预言。

    回复

  9. 我需要检查内核的Rust部分，估计存在大量unsafe代码。如今unsafe的Rust是否有所改进？记得几年前人们抱怨unsafe代码难以编写且极不“符合人体工学”。

    回复

    1. 核心设计理念是：与内核C API交互的大部分不安全代码都封装在内核库中，驱动程序本身应极少使用不安全代码(即使需要也应尽量精简)。

      回复

    2. 这难道不是设计初衷吗？如果体验不佳，人们自然会尽量避免使用。

      (但正如其他人指出的，unsafe代码只应出现在“边缘”场景，绝大多数情况根本无需使用)

      回复

    3. 我认为Rust的unsafe编程并未变得更简单，但除了底层实现(不使用unsafe很难编写Vec)和与C语言交互(其实并不难实现)之外，我也不认为会有太多unsafe代码。

      目前Rust主要用于驱动程序开发。这是我找到的首个Rust驱动程序：

      https://github.com/torvalds/linux/blob/2137cb863b80187103151…

      该代码仅有一个次要用途使用了unsafe——用于支持某类型的发送与同步操作——且显然是临时性的。其余部分均采用安全API。

      回复

      1. 从安全角度看驱动程序颇具趣味性，因为在缺乏IOMMU的系统中，向设备发送错误指令可能覆盖大部分内存。例如，若安全封装允许向PCIe网卡寄存器写入任意数据，便可将接收队列重定向至内核内存页的中间区域。

        回复

        1. > 若安全封装允许向PCIe网卡寄存器写入任意数据

          此类功能在Rust中理应标记为unsafe。Rust的unsafe关键字既表示“此代码块需调用unsafe功能”，也用于限定函数仅能在unsafe上下文中调用——此处显然属于后者适用场景。

          回复

          1. 那么若用Rust编写设备驱动程序…

            – 硬件访问是不安全的 – 内核接口是不安全的

            中间层究竟还剩多少真正安全的操作？

            回复

  10. 然而Linux内核的Rust代码却使用了仅在夜间版编译器上可用的不稳定特性。

    这对简化编译流程和构建旧版内核并不理想(需特定版本的夜间编译器才能构建特定版本的内核)。

    回复

    1. Linux的C语言部分不也高度依赖GCC扩展吗？依赖特定编译器特性似乎并非不可逾越的障碍。

      回复

      1. 区别可能在于GCC扩展已稳定数十年，而Rust实验性特性在版本间存在破坏性变更。因此半年后的Rust版本很可能无法编译当前内核，但十年后的GCC版本仍能正常工作。

        回复

    2. 幸好下载特定夜间版本只需一条rustup命令

      回复

      1. 除了供应链攻击，还能出什么问题？/s

        回复

    3. 如果我告诉你…只需设置一个简单的常量环境变量，就能让稳定版编译器忘记它不是夜间版呢？

      回复

      1. 关键在于不稳定功能无法保证在编译器更新后仍能正常工作。因此才需要指定版本。

        回复

  13. 真的吗？我最近看到报道说“100% Rust内核现已进入Linux 7.4上游”

    回复

    2. 你是在开玩笑吧？毕竟另一条头条新闻里Gemini 3也在幻想十年后的Hacker News。不过还是把这些幻想留在那个页面吧。

      回复

  14. 我不是系统程序员——现阶段C语言相比Rust还有显著优势吗？用C编写的程序是否注定会被逐步迁移到更安全的语言？

    回复

    1. C至今仍是系统ABI的语言，且存在Rust无法实现的功能(主要是位域)。

      此外，在为支持更晦涩的架构而扩展语言方面，Rust做出的若干决策使得某些架构难以获得良好支持。例如，Rust 规定数组索引类型、对象大小类型和指针大小类型均采用相同类型，但某些架构并不支持这种统一性；此外，分段指针等特性在 Rust 中也难以实现(当然，它们在 C 语言中也仅能勉强工作，但至少比完全无法实现要好)。

      回复

      1. 能否详细说明位域？有库通过宏实现位域结构体，虽然未内置于语言中，但实际应用中我不确定Rust在这方面存在哪些限制。

        回复

        1. 确实不太明白他们的意思…我在多个Rust项目中都使用这些宏实现位域。

          回复

          1. 我虽非Rust或系统程序员，但理解为：作为ABI或外部函数接口时，位域因无法精细声明而缺乏稳定性或直观性。

            回复

          2. 这指的是二进制库间的ABI，无论静态还是动态链接？

            回复

      2. 不过开头那句。位域和ABI放在一起讨论。

        位域的打包规则相当复杂。语言面向用户的API固然便捷，但由此产生的ABI却糟糕透顶(尤其在演进过程中)。

        回复

        1. 我希望对位域和结构体进行修订，使其行为符合程序员的预期，同时允许编译器自由建议布局优化方案。同时需要添加标志位，明确告知编译器“此结构已最终确定，禁止调整”。

          回复

      3. usize 与指针的互转功能确实令人意外。就连 Go 语言都区分了指针宽度整型(uintptr)和数据尺寸类型(int/uint)。我只能猜测Rust的这种设计在当时被视为无害的简化方案。这种设计能否通过版本更新修正？我的猜测是无法修正，至少难以实现。

        回复

        1. 像C语言那样(在C++中尤为明显)存在多个语言级类型表示完全相同的值集，必然会带来代价。Rust在早期就做出了相当明确的决策：a) usize是独立于其他类型的基础类型，而非平台特有的typedef；b) 不为uindex/uaddr/uptr等类型增设新定义——这些类型在几乎所有平台上都等同于usize。

          Rust在初始保证中明确指出usize足以实现指针的完整转换(实质上使其等效于uptr)，尽管唯一受影响平台的开发者基本表示宁愿打破该保证，但多位维护者仍对此存有顾虑。更根本的问题在于，许多库完全乐意放弃为特殊平台编译——我设计过依赖64位系统属性的组件，更希望能够声明“在usize≠u64的平台上禁用编译”，从而实现u64的impl From<usize>和usize的impl From<u64>。若存在此类需求，该方案还能优雅地实现“拒绝退出(或退出)usize≠u64编译”的同时保持向后兼容性。

          若想了解该议题的激烈争论，https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-… 是不错的起点。

          回复

          1. > …避免为uindex、uaddr或uptr等类型引入新定义——这些类型在几乎所有平台上都等同于usize。…尽管唯一受影响目标平台的开发者明确表示宁愿打破该保证，但多位维护者仍对此存有顾虑。

            优雅解决此问题的正确方法是使该保证成为目标依赖项。要求所有依赖的crates承认usize可能与uptr不同，从而解锁对“特殊”架构的构建支持——这类似于当前no-std的工作方式。如此一来，“几乎所有平台”仍可依赖该保证，且无需增加复杂度。

            回复

        2. > 能否通过Editions机制修复？我认为不行，至少难以实现。

          若我正确理解了博客文章[0, 1]，size_of::<usize>() == size_of::<*mut u8>() 的假设在不同Editions间是可变的。

          或者至少，如果这种改变(或类似可行的方案)不可行，两篇博文都相当巧妙地避开了明确说明。

          [0]: https://faultlore.com/blah/fix-rust-pointers/#redefining-usi…

          [1]: https://tratt.net/laurie/blog/2022/making_rust_a_better_fit_…

          回复

      4. > C语言能表达而Rust无法实现的功能

        不过反过来说可能更准确。例如Rust原生支持SIMD指令集，而标准C语言根本无法表达这种特性。

        关于这个话题，有篇精彩博文《C并非低级语言》。

        回复

        1. 据我所知，std::simd目前仍仅限于nightly分支。虽然可通过std::arch使用原始内置函数，但这与“#include <immintrin.h>”并无本质区别。

          回复

        2. 那用C语言中相当常见的SIMD扩展就行了，这算不上有力论据。

          回复

      5. 这些类型在哪些架构中存在差异？这种差异是否存在合理的架构依据，还是仅是工具链暴露方式的特殊性(如LP64与LLP64的区别)？

        回复

        1. CHERI采用64位对象大小但128位指针(因指针值除地址外还携带指针来源元数据)。我知道某些GPU指针类型(如纹理指针)的地址大小与指针大小也存在巨大差异。在分段i386架构中，远指针采用16位对象/索引大小，但地址和指针本身为32位。

          我们曾研究过一种加速器架构，方案是将整个数据路径设为32位(节省空间)，同时采用32位索引类型搭配64位指针大小，但最终因实现难度过高而被否决。

          回复

          1. 如今，至少在最新发布的iPhone和Mac中，我们已不再使用128位指针，而是采用64位指针并内置于CPU的隐秘溯源数据。

            最终我仍不确定这是否更优，或许我们本该像CHERI架构那样采用超大指针(当年32位指针空间巨大，我们便将其充作其他用途)，尽管我认为该方案仍存在指针数据的隐秘副车厢问题。

            真希望苹果能更接近CHERI理念。凭借垂直整合优势，他们本可实现重大变革——虽然我认为Mac版Apple Silicon发布时才是最佳时机。

            好奇大容量指针对性能的影响。

            回复

            1. 这并非秘密机制，只是复用了部分闲置地址位。

              回复

      6. 此外无法实现自引用结构体。

        双向链表的实现也相当棘手，而内核中大量使用了这种结构。

        回复

        1. > 此外无法实现自引用结构体。

          你是指安全模式下的Rust吗？通过unsafe和Pin完全可以构建自引用结构体并生成安全API。编译器生成的每个未来类型都依赖这种机制。

          回复

        2. 在内核中使用Rust安全机制几乎毫无益处，我预计内核代码将遍布unsafe代码块。个人认为此举更多是政治游说(美国政府)而非技术需求。对Linux内核开发而言这绝非利好，它必然引入开发摩擦导致效率下降，更可能驱离部分资深内核开发者。

          回复

            1. 抱歉，我哪里说错了？内核开发中编写的代码本质上就不可避免地需要使用unsafe。这类底层代码涉及内存操作和模式，通常在应用程序代码中不会出现。

              我确实研究过那些示例——大约一两年前提交到内核的某个重大补丁中，大量 unsafe 段落让我意识到：就内核开发而言，Rust 可能并不如宣传的那般完美。

              > https://git.kernel.org/pub/scm/linux/kernel/git/a.hindborg/l..

              对吧？感谢举例说明。首先需要明确的是——这并非上游驱动程序而是分叉版本，其作者也仅将其视为概念验证(PoC)。其官网https://rust-for-linux.com/nvme-driver明确声明：“该驱动程序目前不适合普遍使用”。那么，你提供这样连生产级代码都算不上的东西，究竟想证明什么？

              现在进入代码分析。整个代码(不含crates)仅有1500行(？)。规模虽小但尚可。查看不安全代码段：

              rnvme.rs – 8个不安全代码段，其中1个SyncUnsafeCell用于NvmeRequest::cmd(为何如此？)

              nvme_mq/nvme_prp.rs – 1个不安全代码段

              nvme_queue.rs – 6个不安全代码段(实为完整特质)

              nvme_mq.rs – 5处不安全段，2次使用SyncUnsafeCell(分别用于IoQueueOperations::cmd和AdminQueueOperations::cmd)

              总计在1500行代码中存在23处不安全段/特性，而这个驱动程序甚至未达到生产级质量。虽然没时间验证，但若将该驱动使用的所有crates纳入分析，这个数字会膨胀到何种程度？

              抱歉，我无法认同这个观点。

              回复

              1. 安全/不安全划分的设计初衷，是为必须采用不安全编程的代码提供安全抽象层。

                不安全部分需要人工精心编写和验证，但一旦完成，编译器就能确保后续对这些抽象的使用正确且不会引发未定义行为。

                Rust中所有内容在底层都存在“不安全”属性(每个字符串的实现都包含unsafe，编译器本身也使用不安全代码)，但只要底层不安全代码正确，高层代码就能获得安全保证。

                这使得内核维护者能够(谨慎地)创建安全的公共API，大幅提升其他开发者的使用安全性。

                C语言缺乏如此明确的分层机制，其抽象能力较弱，因此无法让维护者创建即使被误用也不会引发未定义行为的API。

                回复

              2. > 你用连生产级代码都算不上的东西想论证什么？

                首先声明：所谓“生产级”C代码在Rust语境下完全属于unsafe范畴。

                > 抱歉，我无法认同这个观点。

                我们根本分歧在于：你在1500行代码中列举了数十处不安全点；姑且认为占10%——你试图将其说成弊端，而我看到相同数据时，却认为这是相较现状的巨大进步。

                回复

                1. > 首先声明：‘生产级’ C 语言在 Rust 语境下完全不安全。

                  我甚至不知道该如何理解这个论断。

                  > 我们的根本分歧在于：你在1500行代码中列举了数十处不安全点；姑且宽容地认为占10%

                  实际远超10%。你连代码都没仔细看，却把这个本质上是玩具驱动程序的例子当作可信证据(?)来支持你所谓我散布FUD的论点。有点可笑。

                  即便仅有10%比例，这些漏洞存在于代码最关键部分的事实，已使Rust安全性的论点失去意义。想必你听说过九成原则。

                  时间会证明一切，但我并不抱期待。我认为这对Linux内核开发是件坏事。

                  回复

                  1. > 这番话实在令人费解。

                    事实就是如此。根据Rust语言定义，其unsafe模式的安全性与C语言相当(严格来说Rust在unsafe块中仍比C安全，但这点可忽略)。

                    > 你连代码都没看就妄下结论

                    我当然看过，但看到的全是单行特质实现(你帖子里的“完整特质”)和几行代码的绑定不安全访问。

                    回复

                    1. > 严格来说Rust在不安全块中仍比C安全

                      实际应用中这点颇值得商榷，因为Rust不安全代码块必须手动维护安全不变量——这些不变量是规范安全Rust编程的基础，包括：引用必须指向有效且对齐正确的数据，可变引用需满足类似C语言`restrict`修饰符(实际罕用)的要求。实践中要始终如一地做到这些很难，可能触发意外的未定义行为。

                      部分安全不变量可通过简单方式放宽(例如 &Cell<T> 可被别名而 &mut T 不可)，但在安全 Rust 中这未必符合惯例或能避免冗余代码。

                    2. 所以，在1500行代码的玩具示例中每70行就出现不安全代码块？这确实是个有力论据。

    2. 确实如此，与C++类似，Rust并非无处可用。

      行业标准基于C或C++，我怀疑它们短期内不会采用Rust。

      POSIX(认证需C编译器)、OpenGL、OpenCL、SYSCL、Aparavi、Vulkan、DirectX、LibGNM(X)、NVN、CUDA、LLVM、GCC、虚幻引擎、Godot、Unity…

      还有众多操作系统如苹果生态，以及大量实时操作系统和嵌入式商业项目。

      此外官方Rust编译器尚未完全实现自举，其存在本身仍依赖C++工具链。

      正因如此，提升C/C++安全性的努力同样值得欢迎——大量现有代码永远无法迁移至Rust，某些领域Rust在未来数十年内仍将处于次要地位。

      回复

      1. 我基本认同你的观点，但值得注意的是，这些标准在主要由非C语言实现和/或使用时，仍可暴露C接口/ABI。虽然我们离这个阶段还很遥远，但C语言在辉煌的RIIR未来:tm:中持续存在并无本质障碍。

        回复

    3. 某些编程风格和数据结构实现方式，几乎会让你在每个步骤都不得不与Rust抗争。比如侵入式数据结构、指针操作之类的情况。众所周知，网上甚至有整本书专门讲解如何用符合Rust惯例的方式编写高效的链表——这在C语言中本是再简单不过的事。

      遇到这类情况时，你完全可以选择用Zig替代C语言

      回复

      1. 考虑到Zig的安全机制，其实用C语言配合静态分析和运行时工具也能实现同等效果——可惜许多开发者始终忽视这些工具。

        只要在Makefile中设置好默认参数，多数人就能完成半数工作，既无需切换到尚未1.0的语言，也避免了内存释放后使用的风险。

        回复

      2. 在Rust中实现链表并非易事，因为链表本身就难以正确实现。Rust将这个问题暴露无遗(确实，暴露得有点过头了)。

        我知道链表本身并不复杂，但Rust确实让它变得棘手。关键在于：构建链表会打破内存安全的核心假设，因此强行在Rust中实现链表注定行不通。

        问题在于，我们中的许多人似乎已遗忘了内存安全的重要性，而编译器如此“提醒”我们确实有些痛彻心扉 🙂

        回复

        1. 需要被包含项协作的容器类，通常通过特殊数据字段实现。例如双向链表中，前指针和后指针作为被包含项的常规成员变量存在。侵入式容器能避免内存分配(在内核中这可能引发正确性问题)，且与C语言缺乏内置容器类的特性相契合。这类容器在C语言中较为常见，但在C++和Rust中极为罕见。

          回复

          1. 至少对于双向链表而言，若编译器能将容器项解箱为节点，非侵入式方案在性能上应能达到相当高的水平？还是说侵入式数据结构仍存在此方案无法实现的优势？

            回复

            1. 若给定结构可能需要存在于多个链表中(据我所记得这是内核的顾虑点)，将数据存储在节点中就行不通了吧？

              而且我认为对于那些不以链表存储为核心特性的数据结构而言，这种形式相当奇怪 (虽不清楚内核具体采用何种方案，但可设想这样的场景：对象99%时间不参与链表，却必须确保即使内存已满(“内存已满无法释放”这类错误想必无人愿见)也能被链入)。

              回复

        2. 一种需要修改数据才能使用的数据结构。

          就像强制你在存储记录时添加下一个指针的链表。

          回复

        1. 没错，若你需要链表(你大概不需要)，就用这个。但若你是极少数需要精细控制定制化数据结构的人——比如需要内部交叉引用之类功能——那么你可能会发现自己置身于这样一个世界：Rust 根本不相信你清楚自己在做什么，每一步都会与你作对。若你确信自己清楚所为，那么 Zig 可能是最优的现代选择。TigerBeetle 团队正是基于这些考量选择了 Zig，网络上诸多资源都阐述了他们的动机。

          回复

          1. 链表的关键在于：完全可以使用 unsafe 设计所谓的“定制化数据结构(含内部交叉引用等特性)”库，再将其封装为安全的接口。

            若你难以设计安全的集合接口，这恰恰表明你的方案可能存在未定义行为隐患。

            Rust标准库的所有集合正是如此运作。它们通过正式验证代码片段，在保障性能的同时确保安全。

            回复

            1. > 若你难以设计出安全的集合接口，这本身就是警示信号——你的方案可能在特定视角下导致行为未定义。

              Rust固然优秀，但某些在抽象层面可证明安全的设计，却难以通过其类型系统直观表达。

              更具体地说，某些事物及其使用模式在组合时是安全的。但库无法利用Rust提供的工具强制客户端遵循安全使用模式。

              回复

        2. 但我认为这偏离了重点。C语言信任你设计自己的链表。

          它同样信任你的邻居、你的孩子、你的大型语言模型、你自己、你的狗、另一条链表…

          回复

    4. 太阳底下所有系统都配备C编译器。Rust却远非如此。Rust虽比C现代，但存在自身问题，比如极其缓慢的编译速度。我猜想当人们从Rust转向其他新潮替代方案后，C语言仍将长期存在。

      回复

      1. 存在一类语言，任何可行的系统都必须支持。目前这类语言大概包括C、C++、Perl、Python、Java和Bash(后两者需打些折扣)。Rust尚未跨过这道门槛，但按当前趋势，它已站在门前，几乎必然会迈入其中。脱离这套必备语言体系绝非易事(我认为只有Fortran和带星号的BASIC真正做到过)，而Perl是我唯一敢押注会在有生之年退出体系的语言。

        我坚信十年内必将出现以Rust而非C语言实现的基准算法，可能是密码学算法或媒体编解码器。当然有人会辩称egg库的e-graphs已符合条件。

        回复

        1. Java从未在企业级服务器之外成为必需，而这类场景本就不关心“任何可行系统”。

          回复

        2. 如今要获得“体面”的桌面软件体验，你同样_必须_依赖Rust。例如由于LLVM不支持某些冷门架构(这些架构现已极其罕见)，Rust无法运行Firefox等软件。

          回复

        3. 系统只需一种编程语言即可实用，而当仅有一种语言时，它基本永远是C语言。

          回复

          1. 若要开发自带C编译器和libc的业余操作系统，C编译器的实现难度(相较于Rust编译器)也相对较低。

            回复

        4. 任何可行的系统都必须支持若干核心语言。当前这套语言组合大概是C、C++、Perl、Python、Java和Bash。

          Java？我认为Java早已不再是必需语言。

          Perl至今仍是关键语言吗？

          回复

          2. 在不依赖Perl的情况下构建任何类Unix用户空间软件极其困难。

            回复

            1. 我真心好奇究竟哪些软件包仍依赖Perl？数量应该不会太多吧？

              编辑：

              在我(Arch)系统中，移除Perl需同时卸载：auto{conf,make}、git、llvm、glibmm等包。

              回复

        5. > Rust尚未完全突破这道门槛，但按当前趋势，它已站到门槛上，几乎必然会跨入。

          我怀疑真正突破门槛的并非Rust本身，而是LLVM。Rust及其生态将借此顺势而入。

          回复

        6. 从我的桌面Arch系统移除Java仅提示卸载两个几乎不用的GUI应用。现在卸载后数月都不会察觉。

          回复

        7. 即便是Perl…它本就不属于POSIX范畴(我相当确定)，更难以想象存在无法用Python等语言重写的Perl关键工具(实际上很可能早已被重写)。

          尽管我喜欢Java，但它对操作系统实用工具也非必需。Bash本身本不该是必需的，但大量脚本实际是Bash脚本而非POSIX shell脚本，且通常缺乏重写它们的动力。

          回复

        9. 我认为现代系统已不再预装Perl

          回复

          1. 我尚未发现未预装Perl的系统，除非你把Windows、控制台系统、桌面/手机操作系统、嵌入式实时操作系统也算进去——这些本就不是正规的UNIX衍生系统。

            回复

            1. 据网络资料(现无法核实)显示，Alpine系统未预装Perl。

              回复

              1. 所以它主要是个用于部署容器的发行版。

                回复

      2. 除了C语言，Linux内核还采纳过什么新潮替代方案？

        我确信C语言会长期存在，但Rust同样具备持久生命力，短期内不会被取代。

        回复

        1. 看到Zig最终进入内核我不会感到意外

          回复

          1. 我会感到意外。主要是因为虽然Zig比C语言更好，但若已有Rust可用，它其实并不会带来太多额外优势。

            回复

          2. 依我之见，Zig本身带来的价值不足以抵消在内核中引入另一门语言的成本。

            Rust则不同，它同时实现了：

            – 通过消除最恶劣的安全漏洞类别，显著提升内核安全性。

            – 通过在类型系统中编码必须保持的不变量，减轻贡献者的认知负担。

            这并非否定Zig在特定项目中的价值，只是它不值得被添加到Linux内核这样庞大的项目中(尤其当项目已拥有C和Rust两种语言时)。

            回复

            1. 恕我无知，但“消除最恶劣类别的安全漏洞”实属大胆断言。难道内核代码中完全不使用Rust的unsafe特性吗？

              回复

              1. 除了极少使用的unsafe代码经过严格审查且是漏洞唯一入口外，它还允许显式结构化地表达内核规则——而此前最多只能在某个代码注释里看到API正确用法说明。这正是因为存在关于如何为某些API实现Rust封装器的讨论，因为这些API的预期工作方式存在歧义。

                因此，除了“Rust中仅1-5%代码涉及unsafe，而C语言中100%代码都存在风险”的差异外，Rust还显著降低了滥用现有抽象的难度(更不用说它在内存安全之外还提供了各类线程安全保护)。

                本质上，这意味着可被利用的缺陷数量减少了一个数量级(基于Android等其他项目的研究)

                回复

              2. 你完全可以编写零不安全Rust的驱动程序。Rust到C的桥接才是存在不安全代码的地方。

                回复

              3. “不安全”Rust仍比C代码提供更多保障。Rust编译器依然强制执行借用检查器(包括别名规则)和类型系统。

                回复

              4. 并非零，但基于Rust的内核(如redox、hubris、asterinas或blog_os)已证明：构建内核仅需极少量不安全代码(3-10%)，且这些代码本就是C内核中最不易引发内存错误的环节 (相较于专注于内存管理模块，开发者更可能在实现与内存管理无关的复杂算法时引发内存错误)。

                因此尽管内核不安全部分确实可能存在可利用的内存漏洞，但其发生频率至少比C语言低两个数量级(据Android团队实践经验，过去几年发现的内存缺陷数量实际减少了3-4个数量级)。

                回复

              5. 它消除了某类安全漏洞(除编译器、标准库/核心库及新增依赖中的不安全代码外)。

                实际应用中，段错误数量会减少多个数量级(如谷歌Android的CVE案例)。可对比Deno和Bun的段错误问题跟踪器直观感受。

                正如无数次强调的：安全带无法避免死亡，但能降低交通事故致死概率。Unsafe并非万能解药，却是相当可靠的解决方案。

                回复

            2. Zig作为语言或许平平无奇，但作为构建系统堪称卓越。若Zig仅凭远超C语言的构建系统(不仅支持跨操作系统交叉编译，更能跨越架构与C标准库版本，包括musl库)而入选，我丝毫不感意外。其配套的测试系统与C语言无缝互操作性，让编写辅助代码变得异常轻松…最终它或许会成为通用开发语言。

              回复

              1. 我认同你的观点——这比语言本身更有趣，但对于内核这类已有成熟构建系统的项目而言，这并不重要。(尤其考虑到即便Zig能让交叉编译变得多么便捷，若从零启动项目——即使借助cargo-zigbuild在Rust中实现——将Linux构建系统迁移至Zig仍需大量工作，且最终可能发现其无法满足内核初期的全部需求)。

                回复

        1. 不过公平地说，POSIX标准正日益过时。

          回复

          1. GNU/Linux并非唯一的操作系统，POSIX的最后一次更新是在2024年(当时C语言要求升级至C17标准)，确实其部分规范在现代平台已显陈旧，尤其在苹果、谷歌、微软的操作系统及云基础设施中。

            不过，申请OpenGroup认证的系统若支持POSIX，仍需配备C语言编译器。

            回复

      4. 我实在想不出多少现实生产系统不支持Rust编译目标。同时期待rustc的GCC后端能取得进展，为更冷门的平台提供解决方案。

        回复

        1. 实际上，任何接近生产环境的“系统编程”平台都具备可用的Rust目标。

          真正遇到棘手情况的是“嵌入式编程”领域——某些奇特平台(或子平台)仅支持C编译器，或虽有Rust编译器但性能堪忧。我们讨论的设备有时甚至没有GCC移植版本(或基于陈旧版本的移植)。这实在可惜，因为在我看来，Rust作为嵌入式编程语言本应大放异彩。

          Linux的情况则稍显特殊，它跨越了边界，常被用作嵌入式设备的内核(尤其需要网络功能的设备)。68k平台用户深受其害——68k上的Linux仍是半主流用例，虽然已有Rust后端的原型，但尚未达到生产就绪状态。

          回复

          1. 据我所知，目前也有将C语言作为中间层的尝试，不过我不清楚具体进展——在性能至关重要的嵌入式领域，这些编译器的优化器已停滞三十年未更新，实际效果存疑。

            回复

        2. 主要应用于嵌入式/微控制器领域。这类场景通常会使用SDCC或厂商工具链，涉及8051、STM8、PIC等主流架构，甚至包括几年前风靡一时的4美分Padauk微控制器这类冷门方案。尤其8051架构至今仍在某些领域活跃，比如CH554 USB控制器或某些NRF 2.4GHz无线芯片。

          回复

          1. 这些平台对C语言的支持实属勉强——我们讨论的是微控制器和封闭式厂商工具链的普遍体验。它们使用的C语言是几十年前冻结的方言，与人们通常理解的C语言截然不同(通常至少指26年前的C99标准，但这些平台最多支持C89，甚至自带限制)。

            回复

            1. 但它终究是C语言，Rust并非可行选项。还能称作什么呢？正因如此，大量嵌入式C库仍采用C89语法。另需说明的是，SDCC似乎支持非常现代的C版本(最高至C23)，因此我认为针对8051或STM8的批评并不成立。我认为C语言正是为这类目标平台而设计，许多如今看来不合时宜的特性(例如不同平台上int的大小差异)都源于此。

              回复

        3. 例如商用嵌入式操作系统、游戏主机等场景。

          回复

          1. 即便厂商和上游未提供官方支持，至少已有团队成功实现了游戏主机适配： https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky…

            我确信若Rust在游戏开发者群体中更受欢迎，游戏主机支持终将迎刃而解——这些主机本质上运行着标准PC架构和常规操作系统，其原生工具链在生成可运行二进制文件方面几乎毫无障碍：PlayStation和Switch采用FreeBSD(分别基于x86与ARM架构)，Xbox则运行x86版Windows，这些均属受支持平台。

            回复

            1. 获得游戏主机支持意味着能生成通过完整审核流程的二进制文件，且主机厂商提供的所有功能都能在首发日获得支持。

              否则就是在做无谓的琐碎工作，而非专注于实际的游戏代码开发。

              有人乐此不疲——Rust等新语言正是如此获得采用，但这类人通常是少数。正因如此，缺乏杀手级项目或企业支持的主流推广之路异常艰难，成功者凤毛麟角。

              更少见的是有人会放弃虚幻引擎、Unity甚至Godot工具链的便利转投Rust怀抱，除非他们更执着于证明“游戏可用Rust开发”这一命题，而非专注游戏设计本身。

              回复

            2. > Switch

              祝你好运把任意二进制文件发送到这个目标平台。2025年独立开发者向任天堂发布作品最高效的方式，就是用Unity创建游戏，再通过任天堂专属版本的工具链进行构建。

              我们认为用Rust完全渗透所有这些开发流程阶段需要多长时间？特别是任天堂——众所周知他们总在首发日就采用最新技术趋势。我们是否认为创造、定位、唤醒并对抗这条巨龙值得付出代价？如今C#搭配增量GC对绝大多数游戏项目而言已绰绰有余。

              回复

              1. 不仅是Unity，卡普空也在其游戏引擎中使用了.NET的分支版本。

                PlayStation 5版的《鬼泣》就搭载了该版本。

                回复

      5. > 编译速度极慢

        情况并非总是如此。编译缓慢通常源于过程化宏和/或泛型的过度使用。即便如此，其编译速度也常与TypeScript、Scala等语言相当。

        回复

        1. 相较于C语言，Rust的编译速度明显更慢。在高性能系统上这或许无关紧要，但资源受限时差异便十分明显。即便全球所有项目都重写为Rust，对整体构建时间的影响也微乎其微。

          回复

          1. 运行时内存问题造成的总成本可能高得多。

            当然这并不否定编译成本的存在，但总能通过在其他机器上编译来规避这个问题。

            回复

        2. TypeScript转译为JS几乎是瞬间完成的，根本没法比

          回复

          1. 值得了解，可惜我的日常项目没这么幸运，只能靠esbuild勉强维持。

            回复

      6. rustc不输出LLVM中间表示吗？LLVM不支持的系统真有那么多？

        回复

        1. 确实存在不少LLVM不支持的冷门平台。

          回复

        2. rustc支持多种后端。据我所知，LLVM后端已完全支持，Cranelift后端也基本完备，GCC后端正在开发中。此外还有独立项目致力于将Rust前端集成到GCC中。

          即便如此，仍存在部分系统短期内仅支持C语言而不支持Rust。例如：- 搭载旧版编译器/编译器分支的系统- 使用违反Rust假设的特殊数据类型(如8位字节)的系统

          回复

        3. 多数组织和环境不会为粗暴处理编译后的Rust代码而转向LLVM。即便LLVM在理论上支持某项功能，也并不意味着相关操作系统发行版会预装该功能。

          回复

          1. 构建过程中使用 LLVM 并不要求全部代码都用 LLVM 编译。它与 GCC 类似，生成的是目标文件，只要这些文件未使用编译器专属的运行时库(如 C++ 标准库或 polyfill 编译器运行时库)，就能将不同编译器生成的目标文件进行链接。

            `clang-cl` 在 Windows 上通过 `cl.exe` 实现此功能。

            回复

          2. 开发者通常能控制开发环境(+/-)，并可自行安装组件。这本身就缩小了受众范围：既要满足使用特殊硬件(如某位用户所言)的群体，又要兼顾开发环境受限的用户群体。

            更不用说从概念上讲，受限环境的用户恰恰是最需要Rust额外安全保障的群体。

            现实固然复杂，但若不持续推进变革，一切都不会进步。

            回复

      8. > 太阳底下所有系统都有C编译器…我猜C语言会存在很久很久，远比人们从Rust转向下一个新潮替代品的时间更久。

        这依然是为C辩护最糟糕的论点。如果C只在无人问津的角落存活，那又有什么关系？

        回复

        1. 我觉得你没抓住重点

          C语言之所以持续存在，是因为它始终无处不在——不仅限于无人问津的角落 :/

          回复

          1. > C语言之所以持续存在，是因为它始终无处不在

            没错，它确实无处不在。但你认为这就是成功吗？

            回复

            1. 好奇你用什么其他标准定义成功？若论实际使用率，C语言依然领先。每年推入生产环境的新代码行数或新启动项目数量，我猜C语言仍位居前列。

              像Rust这类语言或许在“发展年限与普及速度”对比中更成功。现实是大量平台根本不支持其他语言，你别无选择只能用C。Rust无法覆盖多数平台，实际可编译平台更少。除非Linux放弃对大量平台的支持，否则Rust的普及终究有其天花板。

              回复

          2. 它始终存在，也永远无处不在

            “始终存在”的说法有些夸张。C语言发展史的一半时间里，人们都在使用过时的专有编译器，这些编译器随着其架构一同消亡。现代技术如LLVM很容易被人们视为理所当然。

            回复

            1. 这个问题或许很快就能解决——大型语言模型在编译器编写方面表现得异常高效，而C语言本身的设计也便于编译器开发。虽然不确定是否有人尝试过，但近期Reddit上确实出现了相关进展：复活的Java编译器和N64反编译项目。将这些技术整合起来，几乎可以预见：只要有文档和二进制固件转储，就能按需生成针对冷门架构的C编译器。

              回复

        2. 你手头肯定有不少设备搭载着微控制器，其架构恰恰不在LLVM支持范围内。嵌入式领域至今仍极其碎片化。

          话虽如此，其中真正罕见到难以编写 LLVM 后端的架构屈指可数。我理解该项目尚未建立稳定后端插件 API 的原因，但这将有助于支持这些无人愿意主动维护的边缘架构。目前使用实验性后端时，通常需要分叉整个 LLVM 项目。

          回复

          1. > 你手头几乎肯定存在大量搭载微控制器的设备，其架构并不在LLVM支持范围内。

            这正是我的观点。你认为是硬件驱动软件，还是软件驱动硬件？当Rust进入Linux内核后，我猜想未来很难找到值得采用的新硬件，除非它具备Rust支持。

            回复

            1. 在嵌入式领域，硬件对软件的驱动作用远大于反之。绝大多数微控制器即使启用无内存管理单元模式，也无法运行原生Linux内核。当前具备此能力的架构几乎清一色是ARM或RISC-V。现代Linux内核支持的架构清单并不长，但其中不存在LLVM/Rust无法适配的架构。

              回复

    5. 在探讨是否该用Rust重写所有旧代码前，我们更该问：是否所有新代码都已采用Rust或其他内存安全语言编写？

      显然并非如此。这种转变何时实现？15年？或许这涉及代际更替：当那些在内存安全语言环境中成长起来的开发者真正主导软件开发时，距离现在还有多久？

      回复

      1. 我常接触到用Rust、JavaScript或Python编写的新工具，但C语言的占比相对较低。当我在某个新工具的Git仓库里看到“cargo install xyz”时，确实会特别留意。

        回复

      2. 不过我有点担心这是否暗含年龄歧视。我怀疑多数Rust开发者并非“天生”掌握这门语言，而是基于其他语言经验才转而采用它。

        回复

        1. 任何年龄段的人都能学习Rust。现实情况是经验丰富者往往更抗拒学习新事物。

          我能想到几个可能原因：年轻时在学校和职业生涯初期，你接触的大部分事物必然是全新的，而且权威人士(教授、老板)会强制你学习他们指定的内容。你逐渐习惯并擅长适应新事物。后来当你有自主选择权时，反而更不愿改变自己(反而更可能要求新人改变，尤其当存在权衡取舍时)。权力导致腐败，即便在这种微观层面亦然。

          固执与倦怠也有其合理性：你耗费三十年打磨C的技能、工具与效率。面对新项目，即便Rust比C更契合需求，你用Rust真能提升效率吗？一年后呢？两年后呢？…或许根本不值得学习Rust； 继续深耕精英级C技能的投资回报率可能更高。对精通C者而言，这显然更具吸引力——继续打磨这台精妙的机器，还是撞墙自尽？

          对未投入资源者而言，Rust或许回报更高；这无可厚非，让他们去学吧。我们依然需要C++开发者。虽有些阴郁却不无道理：‘进步总伴随着葬礼’。

          回复

          1. > 经验丰富者往往更抗拒学习新事物

            我持相反观点。初学者/准程序员(以及人力资源部门，但这无关紧要)存在某种怪异心态：一旦选择X语言，便注定终生成为X语言程序员。

            而经验丰富者深知：当需要新语言或库时，就该学习新语言或库。掌握几种之后，你会发现它们差异不大——编程终究是编程。当然这看起来像工作，或许“经验丰富”者比“经验不足”者(即年轻人)更抗拒工作、热情更低。

            回复

            1. 经验丰富的人都知道，若需要新语言或新库，就该去学习新语言或新库。

              这很大程度上取决于具体情况——若是接手全新项目，确实如此；或是对现有项目拥有完全重写的自由裁量权。但这类情况往往是例外而非常态。

              即便在全新项目中，框架的生态系统和可用人才储备也通常是需要考虑的因素。

              人生后期还需考虑其他因素，比如成为父母后需要照顾孩子。因此更像是责任增加导致的约束、视角转变和选择受限，而非纯粹自私的权力腐蚀。

              回复

          2. 我依然认为你的观点有误。重申一次，多数现有Rust开发者并非“从零开始的Rust开发者”。他们不急于重写所有C++项目，更多是出于沉没成本考量，以及希望通过全新开发解决新问题。

            回复

            1. > 多数现有Rust开发者并非“从零开始的Rust开发者”

              虽非多数，但软件开发者群体每五年翻一番，且在Stack Overflow最新调查中，Rust在“学习编程”投票者中的占比已与C#持平——考虑到大量人仅为使用Unity才学习C#，这相当惊人。我认为你低估了Rust空白开发者的数量。

              据我观察，近期遇到不少自学Rust却未接触过C或C++的开发者。

              回复

              1. 史蒂夫·克拉布尼克？

                无论如何，那份调查(你本可以附上链接)存在某些问题。

                https://survey.stackoverflow.co/2025/technology#most-popular…

                请切换至“学习编程”标签页。

                > 过去一年中您在哪些编程、脚本及标记语言领域进行过大量开发工作？未来一年您希望继续使用哪些语言？(若既使用过该语言且计划继续使用，请勾选该行两个选项框。)

                描述中提及两个勾选项，但每种语言仅显示单项统计数据。StackOverflow是问题设计失误还是数据出错？

                数据可信度也值得怀疑。难道真的有44.6%的编程学习者接触过或计划接触C++？

                回复

                1. 确实，这份调查存在问题。我正想说每年统计数据的可信度都在下降！我认为这说明对Rust的兴趣并非仅源于需要重写C代码库的人群。半数开发者使用任何工具链的经验都不足五年，更不用说C了，但许多人仍想尝试Rust。我确实认为这会形成代际分歧。

                  > Steve Klabnik？

                  谢天谢地不是。我其实和他辩论过几次。通常部分认同他的观点，但他的粉丝会对任何稍有异议的人投反对票。

                  而且我对Rust也没多热衷：每次尝试使用时，我本能地想用某些功能，结果发现它们都不稳定，我不想处理这些频繁变更，所以认为这门语言仍不够成熟。

                  回复

                  1. 史蒂夫·克拉布尼克，你先引用调查数据，转头又在下一条帖子质疑该调查的可信度？

                    回复

                    1. 好吧，我之前给你点赞了，但现在你简直像个混蛋。这种行为倒也不意外——毕竟有人专门注册多个一次性账号，只为在某个帖子下喷技术方案； 我对Rust根本不怎么关心。很遗憾告诉你我不是克拉布尼克，不过妄想是免费的：也许你觉得所有用-nik结尾的人其实是同一个人，你揭露了阴谋。恭喜你。

                      我本想给你更可靠的数据点，但人们没为我们做足够多的调查，这就是我们有的全部。除非你想参考Jetbrains的数据——剧透警告：那数据明显偏向Jetbrains支持的技术；我不知道还有其他主流数据。

                    2. > 好吧我之前给你点赞了，但现在你纯粹在耍混蛋。

                      大错特错，你描述的正是你自己，不是我。史蒂夫·克拉布尼克，别再撒谎了，好好活出你自诩的模样吧。

                    3. 最初对你抱有善意是完全错误的，这点我承认。

            2. 这很合理；我的论点出于篇幅和时间考虑而保持简化。不过我讨论的是新项目，而非重写遗留代码。

              回复

        2. 此类需求确实大量存在，因此常出现“希望Rust支持GC”这类评论，或是将机器学习衍生语言普遍具备的功能归功于Rust。

          回复

      3. 显然不是

        这很明显吗？最近我没听说过用非内存安全语言的新项目，而且我觉得这类项目很难吸引贡献者。

        回复

        1. 我所知的新型大规模数据基础设施项目大多采用C++(通常是C20)。少量采用Rust(我用过)和Zig，但核心任务仍主要靠C完成，且这种局面在可预见的未来不会改变。

          人们容易忽略：许多系统软件的前沿实现并非开源。它们无需为吸引贡献者而纠结语言选择——身处计算机科学前沿本身就是足够的卖点。

          回复

          1. 当团队招聘陷入困境——无人掌握该语言且无人愿学习时，便到了“不可逆转的临界点”。但C++离这点还很遥远。

            回复

            1. 只要报酬丰厚，总有人愿意编写COBOL代码。

              我目前从事Rust项目开发，可能视野有限，但据我观察，当开发者有选择权时，他们更倾向于使用Rust而非C++(即便不是因为语言本身，至少是出于构建工具的考量)。

              回复

        2. 游戏开发、图形与视觉特效行业、AI工具基础设施、嵌入式开发、Arduino和ESP32等创客工具、编译器开发。

          回复

          1. Zig在营销中至少宣称具备某种程度的内存安全性。实际效果如何我不得而知。

            回复

            1. 依我之见，这和宣称C/C++因使用内存检查器而安全一样不靠谱。

              回复

              1. Zig确实采用非空指针机制，能避免部分未定义行为，但并非全部。

                回复

              1. Zig确实宣称其

                > … 配备调试分配器，能在内存释放后使用和双重释放场景下维持内存安全

                这可能属实(调试分配器确实无法破坏内存安全，尽管该说法仍属强词夺理)。但除此之外，Zig当前并未真正宣传安全性，仅在概述中以“性能与安全性：二选一”为标题提及。

                回复

                1. 不过运行时检查只能验证实际执行的代码路径。此外，如今C语言的内存清理工具也相当出色。

                  回复

                2. 这是库特性(非正式发布版本适用)，而非语言特性。

                  回复

        4. 好奇问下，大型语言模型都使用内存安全语言吗？

          回复

          2. Llama.cpp就叫Llama.cpp，这名字本身就有趣…

            回复

    6. C语言编写起来很有趣。我能写Rust，但更喜欢写C。我更喜欢编译C，更喜欢调试C。我就是偏爱C。

      这就像问：既然市面上已有配备安全气囊和牵引力控制的新款野马，谁还会想开经典款野马？

      回复

      1. 享受驾驶过时危险车辆带来的刺激感无可厚非——毕竟引擎声令人愉悦——只要别给别人添太多麻烦就好。

        回复

      2. > 我更喜欢调试C语言

        我更希望不必调试…我想大多数人都会认同。

        回复

        1. 我更想要免税的十亿美金，但现实就是这样:(

          回复

          1. 在Rust开发中，我多年无需Valgrind或gdb，除非是集成C库的项目。

            内核开发或许没这么轻松，但应用开发中Rust确实将多数问题从调试阶段转移到了编译时。

            回复

          2. 若未说明清楚：我调试Rust代码的频率远低于C语言，原因有二：

            1. 内存安全——这类错误堪称C语言中最难调试的噩梦，因为它们常破坏你用于调试的合理不变量，甚至彻底搞垮调试器！经典案例就是忘记从非void函数中返回值，这会破坏栈结构，导致代码其他完全无关的模块出现各种异常行为。调试起来简直要命！

            2. 更强大的类型系统——你将获得“能编译就行得通”的体验(类似Haskell)。当然并非永远如此，但有时我能写几百行Rust代码，编译通过后首次运行就成功。遇到这种情况时，我不得不压制自己“肯定忘了保存文件，或者增量构建出问题了”的本能反应。

            最终结果是，使用Rust时我在调试器中花费的时间至少比C语言少10倍。

            回复

        3. 这并不能拯救Cloudflare。内存安全固然必要，内存安全防护栏也可能有所助益——前提是这些防护栏在不同层面的成本可控——但内存安全本身绝非万能解药。

          回复

            1. 对许多应用而言确实如此，但程序崩溃对其他应用同样不可接受。若程序崩溃可能导致人员伤亡，那同样不可接受。

              我尚未深入研究Cloudbleed漏洞，但它看起来(与博客所述相反)像是Ragel编译器的漏洞[0]。其他编译器同样支持C语言，例如mrustc将Rust代码编译为C代码(据我理解，mrustc并非严格意义上的编译器，因其假设代码100%正确且通过100%类型检查，实际不执行任何检测)。而rustc的主后端会为LLVM生成中间表示(IR)之类的东西。编译器存在漏洞时——比如rustc——内存安全漏洞通常完全可能发生。

              在Cloudbleed案例中，他们使用的似乎是Colm和Ragel这类古老且可能较为冷门的语言和编译器。当时他们正计划迁移，但遗憾未能及时避开该漏洞。这正是为何冷门编译器和语言难以用于生产环境代码的原因之一。不过对于此类EDSL(嵌入式领域特定语言)，Ragel编译器开发者未能规避此类漏洞确实令人失望——毕竟相较于通用语言编译器，EDSL编译器的开发通常更为简便。

              [0]:

              https://github.com/adrian-thurston/ragel/commit/284f1fb0ba7c…

              https://github.com/adrian-thurston/ragel/issues/44#issuecomm…

              回复

    7. 它比Rust支持更多冷门平台，且用户基础更广泛。

      我不会说所有代码都必然会被重写为Rust，至少未来几十年内不会。C语言陪伴我们半个多世纪，几乎支撑着所有技术的基础架构，迁移这些代码需要漫长过程。

      更可能的情况是，这两种语言将在未来很长一段时间内并存发展。

      回复

    8. 苹果通过为C语言添加内存安全机制(Firebloom)解决了这个问题。他们不太可能放弃这项投资转投Rust。我相信许多公司都不愿抛弃现有代码，而在编写新代码时，总会倾向于借鉴既有技术成果。

      回复

      1. 相较于现实情况，这观点未免过于悲观。你所说的逻辑本应最适用于亚马逊、谷歌、微软等巨头——毕竟它们确实拥有庞大的C代码库。然而这些公司恰恰是最积极采用并推广Rust的先行者。许多其他采用者同样存在遗留的C代码库。

        我并非刻意吹捧Rust或贬低C语言。我先学C再学Rust，甚至在Rust 1.0发布前就已接触。我认为Rust能被接受的原因，也正是这些公司公开提及的：

        C语言作为入门语言确实简单易懂，但代价在于大型应用中必须手动管理堆分配等资源。即便某些代码检查工具能捕捉这类错误，C语言本身对此毫无补救措施。究其根源，我认为在于C诞生于计算资源匮乏的时代，编译器根本无力进行复杂的语法分析。

        尽管人们编写C语言已有数十年历史，但请记住——编写正确的C代码是完全不同的技能，既困难又需要漫长学习周期。若你以为我这么说只是因为自己编程水平差，那就大错特错了。我根本不是程序员(按资质而言)，而是更擅长汇编、寄存器、总线、DRAM、DMA等硬件领域的工程师。即便如此，我仍常遭遇内存错误——编码时稍有疏忽就可能引发。Rust缓解的正是这种压力。

        回复

        1. 所以你想说C语言只适合优秀程序员，而Rust连蠢货都能编程？我认为这是错误的Rust辩护方式。Rust能捕捉某类常见问题，但绝不会神奇地消除逻辑错误。

          回复

      2. > 苹果放弃现有投资转投Rust的可能性微乎其微。

        苹果公司投资了Swift——另一种具备安全保障的高级语言，该语言恰好由克里斯·拉特纳(Chris Lattner)创建，他同时以开发LLVM而闻名。Swift相较于Rust在应用程序和系统编程领域的巨大优势在于：它支持ABI[1]，而Rust众所周知并不支持(除非退而求其次采用C语言的ABI，这将削弱其承诺)。

        [1] 欲深入了解该议题，推荐阅读这篇精彩文章：https://faultlore.com/blah/swift-abi/ 附注：该文作者正是Rust语言std::collections API的设计者。

        回复

        1. Swift似乎不适合操作系统开发，至少不如C或C++适用[0]。据我理解，Swift默认通过引用计数管理大量内存，这种机制并不总是适合操作系统开发。

          [0]：尽管Rust在Linux内核中已非实验性语言，但目前尚未出现纯Rust编写的重大操作系统。

          回复

            1. 但至少内核中的许多任务需要超越引用计数的技术，除非能确保引用计数会被优化掉之类的处理，对吧？

              回复

          2. 关键在于苹果的官方立场——这一点在文档中已有明确记载。

            回复

            1. 实际情况或许比理念更重要。事实证明苹果确实在努力让Swift更适合内核及类似开发场景，比如尝试在可能时自动化移除引用计数，还推出了实验性子集Embedded Swift[0]——该版本对语言特性有严格限制。或许嵌入式Swift未来会大放异彩，苹果的投入确实意义重大，但目前看来它尚未成熟。

              > 嵌入式Swift支持已在Swift开发快照版本中提供。

              考虑到连苹果都开发了嵌入式Swift，说明连苹果也不认为常规Swift适合这类场景。这意味着你的观点无疑是完全错误的。

              [0]:

              https://github.com/swiftlang/swift-evolution/blob/main/visio…

              回复

              1. 你显然忽略了ISO C和C++同样不适用的事实——在这些领域无法使用完整的ISO语言标准，这正是独立运行模式存在的意义。

                回复

                1. 但独立运行模式并非实验性技术，这与苹果所称的嵌入式Swift不同。况且已有完整的大型操作系统内核是用C和C++编写的。

                  你依然无可辩驳地完全错误。

                  回复

                  1. 当真如此？这始终取决于具体讨论的是哪款C编译器及目标平台。

                    对苹果而言，只要满足其自身需求即为合格；对世界其他地区则属实验性技术。

                    我乐于被正确地纠正。

                    回复

          3. 苹果正专门为内核开发扩展Swift语言。

            回复

          4. 操作系统开发采用引用计数机制无可厚非。

            回复

            1. 连内核开发也适用？可有内核采用引用计数作为标准？请举例说明。

              回复

      3. 此外，Swift Embedded的诞生正是源于苹果内部推动Swift替代传统语言的努力。

        回复

    9. Rust编译生成的二进制文件仍比C语言稍大，但差距很小。实际情况因代码复杂度而异，具体需个案分析，且两者性能可趋近。在内存有限的嵌入式系统(约64KB级别)中，几KB的差异仍会造成显著影响。

      回复

    10. 这有点像询问内燃机相较于电动机是否存在显著优势。两者各有优劣。每个使用者都会讲述自身场景下的选择理由，并断言他人绝无可能需要替代方案。

      现有应用中仍存在需要维护的“旧技术”，它们过于陈旧，无人愿意费心用“新技术”重构。况且“旧技术”具备“新技术”无法企及的优势。因此特定场景会继续沿用“旧技术”，而其他场景则会因便利性选择“新技术”。

      回答你的第二个问题：世间万物皆非必然，唯有死亡、税收与机器的淘汰不可避免。Rust如今是新兴技术，但二十年后所有人都会用其他语言重写所有Rust软件(如果那时我们还保留源代码的话——你认识谁会读机器码或穿孔卡片？)。这就是生活。

      回复

    11. C编译器的自举过程比Rust编译器更简单。

      回复

    12. 普及性仍是关键问题。在C语言广泛存在的许多领域，Rust尚未触及。

      回复

    13. 我认为这种替代更像是铁路系统——而非电报线路。电报线路因功能升级被完全取代，而铁路系统经过标准化普及后，虽仍保留部分优势，但主要存在于人迹罕至的区域。

      回复

    14. 海量现有库资源。比如在所有所需外设都拥有Rust驱动程序前，我绝不会用它开发Arduino类项目。

      回复

      1. 为什么？Rust完全能流畅调用C库啊。

        回复

        1. 但这样反而增加了复杂度，却没有额外安全性。

          回复

          1. 若创建提供额外类型信息的封装层，既能获得安全性提升，又能获得更优雅的接口。

            回复

    15. 你是指像Fil-C那样的安全语言吧。

      回复

    16. 取决于具体场景。

      Rust的编译器内置了优秀的静态分析器，通过注解实现生命周期分析和借用检查。我认为借用检查在静态分析中常陷入局部最优陷阱，实际使用体验往往不如预期，但不可否认它远胜于毫无防护。

      C语言拥有更强大的静态分析工具，同样支持注解机制。不过这些都是可选功能，而Rust将它们纳入核心语言特性。你确知Rust代码经过了成功分析，但多数C代码无法提供这种保障。当然，若你掌控代码库，C语言也能达到同等水平。

      C语言还拥有经过全面验证和认证的编译器。若从事特定领域的安全关键型应用开发，这可能是必要条件。Rust在此方面尚无对应方案。

      若将视角转向其他语言，讨论会更具趣味性。就核心语言的功能与用户体验而言，Ada/Spark在我看来均领先于Rust。

      Rust目前仍存在我认为的显著缺陷：编译器速度极慢、缺乏标准规范、支持架构有限(虽在扩展中)、稳定性未达其发展阶段应有水平，且多数Rust代码倾向于使用过多小型库——这与我的个人偏好相悖。

      不过Rust确实风头正劲——此处绝非贬义。这种热度赋予它巨大优势。我怀疑Ada永远进不了内核领域，但Rust却已在此立足。

      回复

    17. 你可以查阅真实系统程序的Rust源代码，比如framekernel这类项目，或是uefi-rs等。

      通过这些案例，你将清晰看到Rust适用与不适用的边界。

      众说纷纭，我的观点是：

      若需频繁使用unsafe，Rust唯一能提供的就是极度反人机工程学的设计。它毫无理由地让编写和调试变得艰难。编写内存安全的C代码其实很简单。Rust解决的问题本身不差，只是其实现方式比编写同等安全的C代码复杂得多。

      语言本身并非安全。用Rust也能写出烂代码，用C也能编出完美安全的代码。

      人们该停止将语言冠以“安全”之名，却用拙劣方式重构他人成果，反而制造全新漏洞。

      回复

      1. 我不同意。Rust的优势在于处理“不安全”操作时，它强制程序员显式声明并隔离内存操作，这极大提升了不变量追踪的可行性。

        用Rust也能写烂代码纯属题外话。你厌倦“用Rust重构世界”的文化，不代表工具本身有问题。

        回复

          1. 1. 这对论点影响不大。多数情况下可审核不安全代码块，某些情形下维护不变量确实需要考虑更多代码。其核心优势仍在于：可围绕这些经过审核的小代码块设计安全接口。

            2. 我认同这更困难，感觉社区多数人都知晓并承认这一点。

            > 或许Rust支持者应花更多精力让不安全Rust更易用、更符合人体工学，而非实质上*削弱安全保障*。除非策略是诱使尽可能多的人使用Rust，再指望他们替你修复问题——这种策略通常用于某些开源项目，而非编程语言。

            我认为没有任何证据表明Rust在削弱安全与保障。事实上所有证据都显示，在Rust替代C和C++代码的场景中，这些指标都得到了显著提升。若有相反证据请拿出来。

            回复

            1. 你仍在犯重大错误，甚至开始攻击稻草人。停止撒谎，停止无能与粗心，做得更好。

              回复

              1. 这是我首次回应你的评论，并非延续任何讨论。

                你并非真诚相待。我将不再与你交谈

                回复

    18. >C语言是否比Rust具备显著优势

      是的，它充满乐趣。Rust则枯燥乏味。

      若想实现功能并享受过程，我永远选择C语言。

      回复

    19. 业余项目我暂时不会改写Rust。现有代码安全性足够，我对C语言很满意。我又不是给火星探测车写程序，普通任务中C比Rust更符合人体工学，尤其在嵌入式领域。

      至于工作代码，关键在于SDK等工具链。例如我即将为Nordic ARM芯片编写固件，其SDK采用C语言，因此我不会为使用Rust而跳过无数障碍和不完善的移植版本，直接采用官方SDK和C语言即可。若情况相反，我自然会选择Rust，但未来十年内这种转变恐怕不会发生。

      正如C从未取代C——尽管它本可完美替代——我也不认为Rust会取代C或C，因为它作为替代方案更为不便。它只会稀释市场份额，这是必然的。

      回复

      1. > 正如C++从未取代C——尽管它本可完美替代

        我认为C++未能取代C，是因为它本身并非劣质语言。它并未在C的核心优势上提供任何改进。

        而Rust做到了。它虽不完美，但若真要取代C，其成功概率要高得多。

        回复

    20. C语言的流行很大程度上源于其标准性和简洁性。我怀疑Rust能否成为未来的“安全语言”，仅因其复杂性。所谓“安全”软件的真正未来早已到来——JavaScript。

      仅存的细分领域：

      * 嵌入式系统 – 始终属于C的领域。内存分配机制使Rust优势无法发挥，且其复杂度让小型系统难以编译器开发。

      * 操作系统/内核 – 几乎所有关键代码都存在安全隐患。实际收益有限。但受资助项目要求驱动，变革终将发生，可能耗时数十年甚至百年。更理想的方案是采用形式化方法验证内核并叠加Linux兼容层，但这终究是空中楼阁。

      * 游戏引擎——Rust因未将自定义分配置于标准库核心而自毁长城。在推出Rust版EASTL之前，其普及速度至多缓慢。

      * 高频交易商——他们本该关注标准库，但正将时间敏感业务从C++迁移至VHDL。我敢打赌其余业务会转向垃圾回收语言，要么Java要么Go。

      * 浏览器——尽管诞生于浏览器环境，Rust仍难有突破。Mozilla已丧失有效变革能力，其Rust项目曾遭扼杀。谷歌拥有全球最大的C++代码库，迁移至Rust的成本将高得离谱，董事会必然否决。

      * 高吞吐量服务——我认为Rust的主要应用场景在此。若大型重构尚未启动，反倒令人意外。

      回复

      1. > 无内存分配意味着丧失Rust优势。

        这种说法并不准确；否则no_std库的存在就没有意义了。数据竞争安全与是否分配内存无关，即使在固定大小的内存池中，生命周期机制依然实用，边界检查依然有效，诸如和类型/表达力强的类型系统等特性也依然适用。

        > 操作系统/内核 – 几乎所有相关代码都是不安全的。

        我认为这种描述有些夸大。据我所知，Redox操作系统中不安全代码的比例约为10%，Steve Klabnik也提到Oxide的Hubris项目中不安全代码比例同样较低(约1-2年前约为3%)[0]

        > 浏览器领域——尽管诞生于浏览器环境，Rust仍难以在此领域取得突破。

        严格来说，Rust早已实现突破。Firefox内已长期存在Rust组件，Chromium也已开始允许第三方组件使用Rust。

        [0]: https://news.ycombinator.com/item?id=42312699

        [1]: https://old.reddit.com/r/rust/comments/bhtuah/production_dep…

        回复

        1. Chrome的Temporal API采用Rust实现。我们确实看到越来越多的浏览器开始使用Rust，不仅限于Firefox。

          回复

      2. > 谷歌拥有全球最大的C++代码库。迁移至Rust的成本极其高昂，董事会肯定会否决该方案。

        谷歌正将安卓系统的大部分代码迁移至Rust，Chromium和V8引擎中现已存在官方Rust代码库。虽然短期内仍会持续编写新C++代码，但他们已投入大量资源为未来项目启用Rust技术铺平道路。

        此外，若你幻想市值数万亿美元公司的董事会会直接决定使用哪些编程语言，或许该审视这份清单中你幻想的其他内容。

        回复

        1. 除非规则变更，Rust在Chrome中仅能扮演次要角色。

          > 根据我们的研究，Chromium最终确定两种方案：

          > 当前仅支持单向互操作：从C到Rust。Chromium以C编写，从main()到exit()的大部分栈帧都位于C代码中，因此我们选择了这个方向。通过限制单向互操作，我们可以控制依赖树的结构。Rust不能依赖C，因此无法直接获取C类型和函数，除非通过依赖注入实现。通过这种方式，Rust 无法进入任意 C 代码，只能通过 C++ 传递的 API 进入函数。

          > 目前仅支持第三方库。第三方库作为独立组件编写，不包含 Chromium 实现的隐含知识。这意味着它们的 API 更简单，专注于单一任务。换言之，它们通常具有窄接口，没有复杂的指针图和共享所有权。我们将对引入C++使用的库进行审查，确保其符合上述要求。

          — https://security.googleblog.com/2023/01/supporting-use-of-ru…

          此外，尽管Rust在Android NDK中比C/C++更安全，但这并非路线图规划内容，Android团队也不会为选择此路径的开发者提供支持。他们仅将Rust用于Android内部系统，而非应用开发者。

          若真要选择替代方案，他们最终支持Kotlin Native的可能性似乎远高于Rust。

          回复

          1. > 除非规则变更，Rust在Chrome中仅被允许承担次要角色。

            我认为Chromium政策已有所调整(可能存在误解)：https://chromium.googlesource.com/chromium/src/+/refs/heads/…

            V8开发者似乎对未来使用Rust更感兴趣，我也很期待看到结果。对我而言，Rust安全模型面临一个重大疑问：它能否有效减少尖端JIT运行时常见的缺陷类型？

            > 他们只将Rust用于Android内部系统，而非应用开发

            我确信如此，仅因~没人真正想用Rust编写Android应用。我认为这对绝大多数应用而言是理性选择——Android NDK本就是丑小鸭，若推出Rust版本，平台会更不重视它。

            回复

            1. 这似乎只是关于如何集成Rust项目的指导原则，并非政策变更。

              NDK官方定位本就不是用于开发应用程序，人们尝试这么做往往是因为不愿接触Java或Kotlin，但自Android 2.0引入NDK以来，这从未成为官方立场。其真正定位是：

              > 原生开发工具包(NDK)是一套允许在Android中使用C和C++代码的工具集，提供可用于管理原生活动及访问物理设备组件(如传感器和触摸输入)的平台库。对于仅需使用Java代码和框架API开发应用的初级Android程序员而言，NDK可能并不适用。然而在以下场景中，NDK仍具价值：

              > 需榨取设备极限性能以实现低延迟，或运行计算密集型应用(如游戏或物理模拟)

              > 复用自身或第三方开发的C/C++库

              因此至少在第一种场景下，Rust本应是受欢迎的选择，但如前所述，他们似乎更倾向于支持Kotlin Native。

              回复

      3. > 嵌入式领域——这始终属于C的领地。无内存分配意味着无法发挥Rust优势，且Rust过于复杂，小型系统难以编译器支持。

        作为嵌入式开发者，我必须指出Rust正日益成为我的关注焦点。在裸机应用中，我实际已用它取代了C/C++。所谓“无内存分配→无优势”的说法我无法认同——Rust在裸机环境提供的开发能力远超C/C++。

        回复

      4. > 不分配内存就等于放弃Rust的优势

        确实存在仅适用于栈内存的安全问题，比如返回指向局部变量的悬空指针。但不触碰堆内存并不能神奇地规避C语言的所有潜在风险。

        回复

      5. Rust已在浏览器领域取得重大突破，尤其在编解码器等领域。Chrome近期用Rust实现的Skrifa取代了FreeType，V8引擎的JS Temporal API同样采用Rust实现。

        回复

      6. > 不分配内存就无法享受Rust的优势。

        内存安全适用于所有内存，而不仅限于堆分配的内存。

        这种说法很奇怪，因为它显然是错误的。难道这是讽刺评论而我没看出来？

        无论如何，Rust的优势远不止内存安全。

        > Rust过于复杂，小型系统难以编写编译器。

        Rust采用LLVM作为编译器后端。

        现有大量嵌入式目标平台支持Rust，相关库也在持续增长。部分厂商已开始提供顶级支持。再次强调，这种说法实在匪夷所思。

        > 几乎所有相关代码都属于不安全范畴，实际收益寥寥。

        不安全代码段并不意味着整个Rust使用场景都变得不安全。这是对Rust认知不足者的常见误解——“unsafe”关键字并不会瞬间抹杀Rust的所有优势，甚至不会消除其安全保障。

        在讨论内核开发者选择推进Rust应用的文章中出现此类论断实属诡异。

        高频交易者——他们本该关注标准库，但其实正将时间敏感业务从C++迁移至VHDL。我敢打赌其余业务会转向垃圾回收语言，要么Java要么Go。

        C++和VHDL不可互换，它们在系统不同层级承担不同职责。他们并非将所有业务迁移到FPGA。

        押注垃圾回收语言很奇怪。尾部延迟至关重要。

        整条评论如此离奇且信息错误，我不得不重读确认这不是讽刺之类的东西。

        回复

        1. > 内存安全适用于所有内存，不仅限于堆分配的内存。

          > 无论如何，Rust的优势远不止内存安全。

          我想对此稍作阐述。Rust通过三种基本模式确保内存安全：1. RAII模式，2. 移动语义，3. 借用验证语义。

          但这三者的组合，其实适用于编译时验证任何“资源”的管理，而不仅限于堆内存。可将“资源”理解为独特且有用的对象——需要时获取，用完后释放。

          对于常规应用，这类资源可包括堆内存分配、文件句柄、套接字、资源锁、远程会话对象、TCP连接等；在操作系统和嵌入式系统中，则可能是设备缓冲区、总线所有权、配置对象等。

          > > 几乎所有相关代码都属于不安全范畴，实际收益有限。

          确实如此，这部分逻辑稍显特殊。“unsafe”的核心理念是将不安全操作的范围限制在尽可能少的代码行内(相同概念可通过不同方式表达，若与您先前的认知不完全吻合请勿介意)。实际应用中，置于unsafe代码块内的部分往往出人意料地精简。无论从何种标准衡量，整个内核都绝非全部采用unsafe模式。

          回复
      7.     > Rust过于复杂，小型系统难以编写编译器。

        我虽非编译器工程师，但想剖析这个论断。据我所知，主Rust编译器采用LLVM框架，该框架使用类似平台无关汇编代码的中间语言。只要能编写词法分析器/语法分析器生成中间语言，便存在独立后端负责从中生成机器码。在我(非编译器工程师)看来，这种设计实现了前端语言(Rust)与目标平台(嵌入式系统)的职责分离。您认同吗？还是说我理解有误？

        回复

      8. > 嵌入式系统——永远离不开C语言。无法进行内存分配意味着无法发挥Rust的优势。Rust过于复杂，小型系统难以编写其编译器。

        现代嵌入式系统早已不同于老式设备。当代嵌入式芯片普遍配备数千字节内存，部分甚至超过1MiB，这种趋势已持续近十年(例如ESP32)。我曾参与基于ESP32的嵌入式项目，全程使用C++开发，包含内存分配器、异常处理等功能，通过SPI接口连接RAM运行效果极佳。如今Espressif官方也在维护一个出色的ESP-IDF Rust移植版本。

        回复

      9. JavaScript中&与&mut并无本质区别。

        回复

      10. > “安全”软件的真正未来早已到来——JavaScript。

        仅限解释器模式下。

        回复

      11. 除非引入魔法宏库或处理引脚等特性，否则Rust并不复杂——这些其实根本不需要。

        这就像说Python因元类而复杂，但你永远用不到它们。

        回复

  15. C++开发者们现在肯定在坟墓里翻身。

    回复

    1. 他们何必如此？

      其他平台可没有领袖既憎恶C++，又接纳另一门同样复杂的语言——甚至像Serde那样拥有双宏系统，简直像Lisp般的巫术。

      自1990年代末以来，操作系统内核便持续采用C编写，而人工智能则依托专为适配C内存模型设计的硬件(CUDA)驱动。

      此外，Rust编译器依赖于C++编写的编译器框架，若无此框架则无法构建Rust编译器，而开发者显然并不急于实现其自举机制。

      回复

    3. 那些懂得谦逊的C++开发者，其实都在用Rust。

      回复

      1. 不，他们看到Rust构建依赖里出现LLVM和GCC时只会微笑。:)

        回复

        1. 没错，它们都是工具。从技术角度看，Rust、C和C++配合得相当好。Swift也是。LLVM LTO甚至能实现跨语言内联。

          我认为C++短期内不会消失。它支撑着所有大型游戏引擎、LLVM、3000万行谷歌Chrome代码等等。绝对是工作马。

          回复
  16.   > Mike：我和Rachel分手了
  >
  > Rachel：Mike，这种方式告诉大家我们结婚了太糟糕了

    摘自该页面梗图区。

    回复

    1. > 同一人迈克在全员邮件中：感谢大家的支持。下周起我将不再担任开发者。感谢我的经理云云…我即将开启梦想中的架构师职位，期待取得成功。

      > 迈克的同事们：哎呀…我们会想你的。

      > Mike的经理：这是你的一周离职通知？我刚提拔你当架构师，你就立刻跳槽去别处当架构师了？！

      回复

    2. 我原本困惑，后来注意到提交页面的真实标题是：“内核Rust实验的终结”

      回复

      1. 这原本也是HN帖子的标题，后来被改了。

        回复

      2. 这多少说明了人们是多么畏畏缩缩、心不甘情不愿地接受它。

        我认为这种态度有道理。在内核层使用比必要更高级的语言毫无益处。争议焦点在于内核是否需要现代化，但核心问题应是：哪种工具最适合这项工作？抛开花哨功能，请回答：使用Rust能否比C语言的最佳实践产生更高效、更优化的结果？

        这无关人们偏好哪种语言编写应用程序。内核的本质是以最小开销实现功能。

        打个比方：Linux内核历来是精工匠人指导的小作坊，而微软历来是秉持务实作风的大企业。如今却有人主张Linux该变成“听听大家意见——不，他们不喜欢你的老办法，而你已无力管理”的作坊模式，这固然可悲，但如今处处皆是如此。这并非二十世纪那种嬉皮士啃苹果吸毒却创造出电子游戏和图形操作系统的革命，不过是因厌弃旧法而弃之，转而拥抱新法——因新法看似足够优秀，更易管理，更能吸引新人加入。这就是微软式渗透。

        回复

        1. 内核级别的Rust使用体验，其抽象程度其实和C语言相差无几。

          回复

          1. 是啊，我完全搞不懂他们在说什么鬼。

            回复

    3. 我当真以为Rust要被移除了。

      好梗！

      回复

  17. 这个标题略带标题党意味，隐含Rust可能被移出内核的暗示。建议改为“内核中的Rust不再处于实验阶段”

    回复

    1. 我完全理解这种情绪，但LWN作为顶尖出版物，难得也忍不住开个玩笑——况且读者群大多能立刻领会这是反讽。

      作为订阅近二十年的老用户，若没有LWN海量优质内容提供的高质量教育，我的职业生涯恐怕根本无法起步，至少会逊色许多：让我们宽容些吧。

      回复

      2. > 难得见此情景忍不住开个玩笑

        作者声明实属无心之失

        > 哎哟。会议期间仓促发文果然招致误解。我的本意并非如此——实验已完成且成功，仅此而已。

        回复

        1. “哎哟”是指被拿来和Phoronix比较。

          有人觉得他们报道不准确吗？或者内容浮夸到影响质量？

          我倒没发现——不过说到底，我可能主要看聚合站分享的优质文章。

          回复

          1. “哎哟”的反应我不清楚，但评论其余部分显然表明他们无意暗示这是标题党。

            回复

          2. 不，我以前常看Phoronix，虽然文章有时有点标题党，但总体还行。真正的问题是读者评论区——简直一团糟。

            回复

      3. 有道理。但刻薄的标题党和“用标题传递与事实完全相反的印象”还是有本质区别的 😉

        回复

      4. Hacker News通常会删除标题党标题，无论来源如何

        回复

    2. 如果真被删了，标题会变成“内核中Rust语言的更新”

      回复

    3. 我觉得在HN上，大家普遍希望投稿标题和页面标题一致。

      (不过我也承认标题确实有诱导点击的嫌疑)

      回复

      2. 我认为在HN上，人们浪费太多时间争论标题措辞是否属于点击诱饵等问题，却很少讨论文章实质内容。

        回复

      3. 我通常支持优化标题，但此例例外。这恰是反讽之处——LWN根本不需要点击诱饵。

        回复

        1. 这显然是作者的真实失误。但我认为应保持原貌，围绕它的混乱与争论本身就很有趣。

          回复

    4. 标题略带噱头，但文章简洁有力，读来畅快淋漓。若真有优质的点击诱饵，此文堪称典范。精彩之作！

      回复

      1. 不如直接引用原文：

          Rust实验话题刚在年度维护者峰会上讨论过。与会开发者达成共识：内核中的Rust已非实验性功能——它已成为内核核心组成部分并将长期保留。因此“实验性”标签即将移除。谨向所有Linux版Rust团队成员致以祝贺。
        回复

      2. 或许吧，但可能适得其反。我先是惊讶，接着失望，差点没点链接或讨论就离开。幸好我点了。但好标题不该误导！(公平地说，这个标题虽未误导，但至少令人困惑。)

        回复

    6. 他并非故意的！不过标题确实吸引了我。

      回复

    7. 我产生了似曾相识的感觉。几周前这里是否出现过极其相似的标题？

      回复

    8. 看来你不懂“乐趣”的概念。学会理解它能让生活更轻松。

      回复

      1. 默认提供额外安全保障，同时允许用户选择退出——这才是真正的自由。

        回复

    2. 这就是为何全球多数地区数十年未采用C/C++的原因。

      回复

      1. 我虽不追随Rust潮流，但此类论断完全站不住脚。

        大量软件采用C/C++编写，只因它们曾是数十年的唯一选择。当你负担不起垃圾回收机制，又需要直接操控硬件时，别无他选。倘若当时存在“更安全”的替代方案，开发者很可能就会选择它们。

        直到近年才出现真正能取代C/C的语言，比如Rust、Zig和Odin。我并非断言它们必然或应当取代C/C，只是强调如今我们确实拥有了替代选择。

        回复

        1. 至少在PC领域，你可以选择Delphi，或者更早的Turbo Pascal。

          至于其他替代方案，我在此就不一一列举了。

          回复

        2. 三十年前就能用Perl重写curl。Java、Go、Python等语言同样可行。但时至今日它依然用C语言编写。

          回复

          1. 若你试图通过“有人选择C而非Perl”来论证Rust的优越性，我不得不质疑你对C语言积极特性的认知程度——更遑论Rust了。

            回复

          2. 你的评论在我看来颇为虚伪。例如若用Java实现，将受限于JVM环境，而这仅是curl当前应用场景的极小部分——尤其当我们讨论的不是“命令行工具curl”而是libcurl库时。我感觉你心知肚明，纯粹是想挑刺。顺便提一句，维基百科显示Go语言诞生才16年。

            回复

        3. 众所周知，C++和Rust之间根本没有发布过任何编程语言。

          回复

      2. 若讨论的是操作系统内核领域，此言并不成立。

        回复

        1. 操作系统内核？从numpy到CUDA再到NCCL，无一不是用C/C++实现的(承担所有幕后重任)，更不用说经典系统软件如网页浏览器、网络服务器、网络控制平面(此类例子不胜枚举)。

          回复

          1. 新一代Web服务器早已摆脱C/C++的束缚。

            数十年来，网页浏览器始终基于C/C++的受限子集编写，并辅以大量专用工具链，如今正逐步转向Rust语言。

            回复

            1. 目前没有主流浏览器采用Rust开发。即便新项目Ladybird也选择了C++。

              回复

              1. Firefox和Chrome已包含大量Rust代码，且占比持续增长。

                回复

                  1. 根据https://4e6.github.io/firefox-lang-stats/统计，占比12%。

                    我希望能看到[https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9e…]的更新版本 (https://docs.google.com/spreadsheets/d/1flUGg6Ut4bjtyWdyH_9emD9EAN01ljTAVft2S4Dq620/htmlview#gid=885787479) 的更新版本(该版本数据截止于2020年)。

                    至于Chrome浏览器，我不确定是否有人统计过相关数据，但从https://chromium.googlesource.com/chromium/src/+/refs/heads/… 至少能看到大量vendored crates，说明存在一定程度的使用需求——这符合逻辑，毕竟官方在2023年宣布过支持计划。

                    回复

            2. > 数十年来，网页浏览器始终采用C/C++的受限子集编写，并辅以大量额外工具链

              所以说C/C++编写的？你似乎在强行论证一个与现实相悖的观点，却固执地坚持不懈。

              回复

              1. > 所以是用C/C++编写的？

                并非那些主张用C/C编写新代码的人通常所指的意思。如果有人主张遵循Chrome相同的开发流程，那是个可辩护的立场。但如果有人主张在没有任何功能限制或额外工具的情况下用C/C开发，并辩称“没问题，因为Chrome用C/C++”——那是不行的。

                回复

      3. 如今多数软件开发都是JS/TypeScript的烂代码，流行不等于优秀

        回复

        1. 任何语言都能写烂代码，当然也能写出好软件。

          回复

          1. 我从未见过任何JS/TypeScript代码能称得上“写得漂亮”。

            回复

            1. 我见过。我个人非常欣赏近期为网页开发的UI框架，比如Solidjs或Svelte这类工具。

              无论你对React有何看法，JavaScript社区始终是探索新型用户界面编程方式的先锋。他们为此耕耘数十年——自jQuery时代起便如此。其他编程领域仍在追赶，比如SwiftUI。

              VSCode也是款出色的轻量级IDE。尽管基于Electron构建，其运行速度和稳定性却远超XCode。

              回复

      4. 世界多数人使用其他语言是因为它们更简单，而非更安全。

        回复

        1. 它们之所以更易用，正是因为在诸多改进中包含了安全性提升。

          回复

      5. 安全带发明前，人们根本不使用安全带。

        回复

      1. 疯子们认定Rust属于文化战争中“觉醒派”阵营。阅读Phoronix评论区简直滑稽至极——任何关于Rust的帖子都会演变成一群老家伙抱怨“蓝发觉醒派Rust程序员”之类的无稽之谈。

        回复

      2. 八成是些无稽之谈，毕竟我们身处两极分化的时代，思想都被压缩进150字符的推文里。

        回复

        1. 赞同，这种模糊发帖正是顶层评论别有用心的表现。既无超链接也无具体细节，简直像填空游戏——任君在此处填入你的怨言。

          回复

    2. 事情并非如此。一旦掌权，先锋主义就会通过压制所有异议来维护自身。它不会消散，反而像病毒般蔓延。

      回复

      1. 或许如此。但另一方面，随着社群壮大并呈现政治多元化，人们终将不再因使用特定编程语言就被贴上讨厌的政治标签——这难道还不够好？

        回复

  20. 天哪，你能想象未来Rust内核的复杂程度会有多令人窒息吗？

    回复

    1. 据多数评价，Rust4Linux项目通过强制解决技术债务和改进劣质API，反而降低了内核的复杂度。

      回复

      1. 这让我很感兴趣：是否有清单列出被移除/改进的糟糕API及已解决的技术债务？若无清单，能否举些典型案例？

        回复

    2. Linux内核本就极其复杂，我认为用Rust代码替换大部分或全部内核代码将有助于提升可理解性。至少因为Rust能用比C语言更精密的类型表示复杂状态。

      回复

    3. 是否有量化指标能证明复杂度会因此增加？

      回复

    4. Rust的复杂性不过是将现有复杂性编码化罢了。

      回复

      1. 我最近在为C语言SDK开发Rust绑定，结果发现Rust封装代码的复杂度远超被封装的C代码。最终我不得不妥协：通过限制使用场景来获得合理的封装，而非完整复现C API的所有功能。某些合理的内存所有权模型在Rust的所有权机制下确实难以甚至无法表达。

        当然，若最初就采用Rust开发，我们本会选择更易建模的替代方案。但现实是现有C语言模型正是我们需要封装的对象。此外，更符合Rust特性的模型将导致更高的内存开销。

        回复

        1. 我完全理解你所说的C友好型API在Rust中难以适配的问题。GTK就面临这个困境——几个月前我尝试用Rust基于gtk构建原生UI，结果糟糕透顶。

          > 此外，更符合Rust特性的模型将导致更高的内存开销。

          能否具体说明？我的实际体验并非如此。

          总体而言，Rust的所有权模型促使我采用严格树状结构的设计，由于所有内容都紧凑地封装在内存中，这种设计非常高效。相比之下，我接触过的多数C++ API都构建出对象嵌套结构，指针四处指向。这种风格不仅内存效率低下，还会因页面错误导致性能下降。

          C语言拥有安全Rust所缺失的若干技巧。但反观C语言，其泛型缺失导致大量程序自行实现哈希表、数组列表等工具。这些实现要么采用动态类型(效率极其低下)，要么通过宏技巧处理类型参数——简直丑陋至极。泛型和单态化的缺失使C程序的二进制文件通常略小。但运行速度往往不如前者。在现代计算机上，这通常是得不偿失的取舍。

          回复

        2. 具体哪个SDK？我只用Rust FFI实现过基础C API，想了解更复杂场景的局限性

          回复

    1. 为什么？你对运行Rust代码过敏吗？要知道，执行二进制文件时你根本无法分辨语言？

      我不喜欢用Go编程，但这并不妨碍我在电脑上运行Go程序。我的电脑似乎毫不在意。

      回复

    3. BSD开发大多沿袭经典模式：假装只要写完C代码再死死盯着它看，代码就会自动正确。

      其实不确定他们是否真做到单元测试阶段。

      (OpenBSD额外添加了无数安全缓解措施——这些措施据称是梦中启示，实际根本不起作用。)

      回复

      1. 他们什么都不做，却能让《自然计算之美》里某个C语言垃圾段代码崩溃。你根本不懂BSD体系，每个BSD版本都互不关联。

        回复

  23. 说实话，文章前半段还挺有道理。我原以为他们放弃是因为Rust太复杂不适用，结果恰恰相反。

    回复

  24. Linux的发展方向早已偏离正轨，这不过是趋势的印证。

    回复

  25. 我并不精通Rust，甚至从未写过一行Rust代码。我担心此举将从根本上分裂内核开发者群体。这绝非Linux所乐见。在微软对Win11彻底失控后，Linux本是备受推崇的替代方案。我忧虑Rust的现状(以及开发者间的纷争)将驱离用户。仅供参考。

    回复

    1. 若闹剧真能驱散Linux内核开发者，托瓦兹早该独自耕耘三十年了。无论好坏，这个社区早已进化出对抗冲突的强大免疫力。

      回复

    2. 1. 哪个剧？

      2. 终端用户完全不在乎应用程序(或操作系统——他们分不清区别也不关心)是用哪种编程语言编写的。他们只在乎它能否快速、安全、轻松地完成所需任务。

      回复

      1. 我猜他是指Rust团队声援乌克兰并向所有受冲突影响的人表达同情？含糊其辞的发帖实在难以揣测。想来入侵/吞并战争这类话题太过敏感，公开反对恐怕不妥。

        “在介绍新版Rust的细节之前，我们谨此声明：我们与乌克兰人民站在一起，并向所有受此冲突影响的人们表达支持。”

        回复

  26. 好奇他们如何在失去Rust保障的情况下维持长期安全性。这种权衡终将难以维系。

    回复

    1. 建议你读读这篇文章。

      (剧透预警：Rust已升级为内核中完全平等的核心组件，不会被移除。)

      回复

    2. 虽然很晚了，但我实在费劲理解这段话。能解释下你的意思吗？

      回复

      1. 我猜他们只看了标题没读正文，误以为Rust要被移除，于是(若属实倒也合理)认为这是短视之举。

        (当然实际情况并非如此。)

        回复

        1. 啊！我之前没考虑到这点，谢谢。这样解释通多了——读完文章后我实在没法理解这里的意思。

          回复

  27. 这太棒了，因为这意味着某天(可能很快)Linux开发将逐渐停滞并变得无法维护，这样我们就能从头开始编写新内核了。

    回复

    1. 或者你可以理解为：Linux内核正在接纳现代编程语言，以便吸引更多程序员参与贡献 🙂

      回复

      1. > Linux内核正在接纳现代编程语言，以便吸引更多程序员参与贡献 🙂

        我热切期待Linux内核重写为TypeScript的那天，这样就能吸引更多程序员参与贡献啦 🙂

        回复

  28. 在内核中引入Rust似乎是转移视线。若要实现容错和安全性，将Linux迁移至微内核架构岂不是更优解？这样驱动程序及其他组件就能被隔离在沙箱中。

    回复

    1. 我虽非系统程序员，但据我所知，托瓦兹长期以来对微内核持强烈反对意见。该概念在理论上看似更简洁，但其复杂性远超潜在收益。从我关注的讨论来看，这场辩论与更广泛软件开发领域中单体架构与微服务架构的争论如出一辙。

      回复

      1. 我虽非内核开发者，但知晓90年代初塔纳鲍姆与托瓦兹的论战。据我所知，林纳斯向塔纳鲍姆阐述单体设计的根本理由是性能考量，不过到了2025年，这点已不再那么重要。

        感谢你没有刻薄回应或投票反对就尝试解答我的问题。通常HN比这里更适合讨论。

        回复

        1. 林纳斯的诸多观点主要基于90年代的经验，如今已不具参考价值。世事如此。

          回复

    2. 微内核架构并不能神奇地消除漏洞，它只是将部分内核崩溃替换为应用程序崩溃。漏洞依然存在，持续影响用户，仍需修复。

      Rust语言仍能有效消除此类缺陷。

      回复

      1. 我认同它无法神奇消除缺陷，且重构现有Linux内核并非可行方向。但将操作系统服务拆分为权限受限的应用程序，在崩溃时仍能形成有效的安全屏障。现状是：一旦发生完整的内核空间远程代码执行，Linux系统就彻底完蛋了。

        回复

    4. 直接用MINIX或GNU Hurd系统不就得了。

      回复

      1. 更妙的是效仿阿米什人，尽可能自己动手打造系统。

        回复

    5. 你应该基于该架构开发小型实验内核，并在邮件列表发布。

      回复

  29. 虽然完全无关，但若能原生运行Wasm就太棒了。

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

你也许感兴趣的：