Debian的APT即将强制要求Rust支持：各移植版本需适配或面临淘汰
Debian开发者Julian Andres Klode在万圣节发布了一则消息，可能让部分Debian Linux用户和开发者感到不安：明年APT打包工具将开始强制要求Rust编译器。这意味着Debian Linux将对所有架构提出Rust支持的硬性要求。当前虽有移植但缺乏Rust支持的Debian CPU架构，需推进支持工作或面临淘汰。
朱利安周五宣布，计划于2026年5月前在APT中引入强制性Rust依赖。
在APT代码库的某些领域，采用内存安全的Rust编程语言具有显著优势，因此在Debian生态中强制要求Rust是合理的：
“我计划在2026年5月之前将Rust编译器、标准库及红杉生态系统引入APT并强制要求依赖。
特别是解析.deb、.ar、.tar文件的代码，以及HTTP签名验证代码，将极大受益于内存安全语言和更严谨的单元测试方法。”
这使得某些Debian移植版本（如较为冷门的m68k、惠普精密架构(HPPA)、SuperH/SH4和Alpha架构）陷入困境——当前缺乏完善的Rust支持，却又作为移植版本存在。这些项目需推进Rust支持工作，否则将面临Debian移植版终止的风险：
“若您维护的移植版尚未配备可用的Rust工具链，请确保在未来6个月内完成部署，否则该移植版将被终止。
整个项目必须能够向前发展，依托现代工具与技术，而非因将现代软件硬塞进老旧计算设备而受制于人。”
Julian的完整公告可查阅邮件列表。
是时候了。关键基础设施仍用C语言编写——尤其是处理不可信来源数据的代码——这种技术债务只会随着时间推移愈发严重。Rust的编写难度其实并不比C高多少。Rust的设计初衷正是基于当今对语言设计和代码安全的认知，重新打造C语言的理想形态。
既然出于实用考量可以放弃32位x86支持，这些架构同样可以被淘汰。若真有人执意要将这些架构作为未来持续运行的平台，就该挺身而出为Rust工具链创建支持它们的后端。
当前基础系统中被视为核心应用可行语言的约有五种：C、C++、Shell(特指bash)、Perl和Python。其中Python是约二十年前新增的成员。这并非意味着所有人都青睐这些语言(事实上，我认为不少评论者若得知C++不仅在列，且已存在至少25年，定会大感意外)。
其他语言(如Java、PHP、Go)虽被视为可接受甚至理想的应用开发语言，但Rust实为首个在性能上足以与C抗衡、从而引发将其纳入基础系统语言列表讨论的语言。我认为唯有Go曾接近这个门槛，但从未见其被考虑用于systemd这类系统组件。
有趣的是，我好奇当年将C++、Python和Perl纳入基础系统语言集的争论是否同样激烈。
我认为任何由自诩为“X派人士”(如Python派、Perl派)主导的项目，面对新语言加入其视为语言社群一部分的项目时，总会产生些许抵触情绪。
假设你是位C++开发者，多年来为APT贡献代码，将整个项目与自身所属的C++社区紧密相连。此时若有人提议将部分功能迁移至Rust/$NewLang，这种改变对他们而言可能不仅关乎代码本身——无论好坏，都可能触及他们身份认同的核心(用“攻击”这个词或许偏重了些)。
> Shell(此处应特指bash)
Debian正持续推进多项工作，旨在使众多shell脚本(如软件包中的postinst脚本等)摆脱对bash的依赖。
精简版Debian系统不包含bash，而是使用dash，后者不支持bash扩展功能。
> 精简版Debian系统不包含bash，而是使用dash，后者不支持bash扩展功能。
请勿随意编造事实，这些内容本可轻易核实。
所有精简版Debian安装都包含bash，因为它是必备软件包。此处“必备”的定义参见https://www.debian.org/doc/debian-policy/ch-binary.html#esse…
无论是通过安装程序的基础安装，还是使用debootstrap，我从未见过缺少bash的情况。
为避免混淆：'sh'是软链接指向dash的符号，而非bash。
> 基础系统中核心应用程序可接受的编程语言约有五种：[…] Python
不知你是否尝试过运行他人编写的Python程序——如今它已沦为灾难，几乎必须依赖容器才能精确复现原始开发环境。
核心系统应用应是仅依赖默认全局库的二进制程序，外部依赖应降至绝对最低限度。老天，我甚至认为系统修复关键路径中的应用程序(如apt)都应采用静态链接——毕竟我们早已摆脱存储资源受限的时代。
> 不知你是否尝试过运行他人编写的Python程序？如今这已演变成灾难性局面，实际上必须依赖容器精确复现原始开发环境。
请举例说明你认为“仅为运行代码就必须依赖容器”的项目，我定当竭力反驳。
> 毕竟我们已不再生活在存储资源受限的时代。
既然你抱怨容器问题，说明你其实很在意存储使用量。
我当然在意，这是原则问题。这些开销会累积起来。
基于我推测与配置不当的CI相关的因素，pip每年被下载数十亿次(https://pypistats.org/packages/pip)，且我认为这些文件会被持续解压复制——毕竟使用uv安装pip毫无合理性可言。这意味着数十拍字节的磁盘I/O消耗。
> 请举例说明你认为“必须使用容器”才能运行代码的项目
我猜GP所说的“容器”是泛指，包括pipx、venv或uv这类工具。根据PEP 668规范，这些工具确实是必需的：
https://stackoverflow.com/questions/75608323/how-do-i-solve-…
对于环境已知的发行版而言，这通常不成问题
这根本不是问题，却逼得他们往pip里硬塞了句“去你的，这Python归发行版所有而非你”的警告，还要求用户同意“破坏系统”才能使用。
在所有语言中，基础系统里的Python堪称彻头彻尾的垃圾。
> 迫使他们硬塞进
这并非他们所为，更谈不上黑客行为，该提示也并非来自pip本身。
该机制依赖pip主动识别标记文件，其定义由https://peps.python.org/pep-0668/制定——这是多个Linux发行版、pip及Python官方代表共同参与的成果。(许多其他工具完全忽略系统Python环境，我的工具默认也是如此。)
此外，这些机制并不意味着安装普通项目必须依赖容器。
更重要的是，这并非Python独有的问题。发行版根本无法打包所有可供下载的Python软件；要求使用Python原生打包系统的用户不干扰不理解该系统的发行版包管理器，完全合情合理。尤其当发行版希望用Python创建自身工具时。
你之所以只在Python上注意到这个问题，是因为发行版不会预装JavaScript、Ruby等语言来支持系统。
核心系统Python应当位于/usr/sbin目录且设置为只读(前提是Python能容忍__pycache__这类垃圾文件)。
用户不得不应对多重PEP规范、错误提示、–single-version-externally-managed参数、–break-system-packages选项、遍布各处的配置文件、隐藏在.local目录的包，以及用uv工具来修补这些漏洞——这一切都证明Python的打包机制已彻底崩溃。
> 系统核心Python应位于/usr/sbin
“系统Python”仍具备相当扩展性。我的版本包含NumPy、GTK/QT5/QT6绑定库、Freetype、PIL等组件…
> 只要Python允许其__pycache__垃圾文件存在
据我理解，这正是标准库在安装过程中预先编译的原因(此时进程已具备sudo权限，因此能够在指定位置创建
__pycache__文件夹)。此机制利用了标准库的compileall模块——摘自Makefile：> 用户不得不应对多个PEP规范、错误信息、–single-version-externally-managed参数、–break-system-packages选项、遍布各处的配置文件、隐藏在.local目录的包，以及用uv工具来掩盖所有这些问题——这充分说明Python的打包机制已彻底失效。
请勿散布恐慌性言论。
用户根本无需处理这些问题。他们只需创建虚拟环境——名称可自定义，且标准库明确支持此操作。更重要的是，阅读PEP文档对终端用户毫无意义，这些文档仅阐述了如–break-system-packages等变更的动机。开发者或许关注PEP文档，但https://packaging.python.org能提供更精炼的必要信息摘要；其中提及的问题均与Linux系统级Python环境无关。开发者真正关心的配置文件位于项目根目录。
如今在任何Debian系统上，安装yt-dlp等用户级工具时可选择多种方案，例如：
只需掌握其中一种方案即可构建正常运行的系统。
> 他们只需创建虚拟环境即可
好吧，为编写五行脚本我必须创建虚拟环境。每次使用时还得反复激活/停用环境，还要记得定期更新依赖项。就为了这区区五行脚本。
在我看来，管理大型代码库的公司将他们的权衡方案强加给了所有人。
谢谢！这正是我想阐明的观点。
然而，若我编写Dockerfile需要使用Perl，系统自带的Perl完全够用。
但若需要Python脚本，就必须把所有RUN指令都封装在容器内的虚拟环境中。
大家对此过于苛责了。安装版本管理器并将其设为Python主版本本就不难，这本就是良好的开发习惯。
我理解其逻辑在于：基于Python的系统包通过pip等工具管理依赖会带来系统稳定性风险。因此他们选择了更保守的方案，这符合其一贯作风。
老实说，若真要找个容易出这种幺蛾子的发行版，Debian当之无愧。真不明白有人怎么敢不用添加大量APT源和语言版本管理器就直接用这个发行版。
没错，因为这样你就开始使用非发行版提供的Python包了。若真要这么做，请务必使用虚拟环境，别无他法(即便基础系统未预装Python也一样)。
没错，发行版维护者坚信虚拟环境是最佳实践——但这只适用于你，不适用于他们。
这背后有充分理由。普通用户根本不会关心某个发行版打包程序是用什么语言写的。他们只想直接运行ubxtool、gdal_calc、virt-manager等工具，无需配置虚拟环境。而Python开发者若选择使用非发行版打包的版本，就应该精通这类操作。
棘手之处在于当“用户”因他人建议开始使用pip安装软件时。
这应该成为官方错误提示！
能否展开说明？我真心好奇为何Python场景下这不算问题
这要求普通用户证明否定命题。你具体遇到过哪些问题？为何认为这些问题普遍存在？
存储对Debian至关重要！在嵌入式Linux领域，除了自定义系统外，4GB或更小的eMMC存储器相当普遍。
这根本不是问题。真希望别再重复这种说法了。
X11/KDE是否属于“基础系统”范畴？若属实，那么：
…其实并不意外。
Debian基础系统要小得多。我惊讶于人们竟认为Python是其组成部分。不过APT依赖Perl和C++运行时库，因此这两种语言早已是基础系统的一部分。
> 令人惊讶的是人们竟将Python视为基础系统组成部分。不过APT确实依赖Perl
恕我难解？
Debian 不会在 /usr/local 目录下分发文件。
当然你可以自行在 /usr/local/bin/apt 路径下添加“apt”二进制文件，使用任何语言编写都行——比如 COBOL、Java、Common Lisp 或 Python。
那是什么版本的apt？?
file `which apt`
/usr/bin/apt: ELF 64位 LSB pie 可执行文件，x86-64架构，版本1 (SYSV)，动态链接，解释器 /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=157631f2617f73dee730273c7c598fd4d17b7284, for GNU/Linux 3.2.0, stripped
我好奇其中多少 Perl 支持只是正则表达式和其他解析工具。
我在基础操作系统中注意到这类情况很多
不过这更多是出于好奇
apt有相当大一部分是用Perl编写的。即使应用程序使用得少了，它对Debian来说仍然相当核心。
APT本身没有Perl代码，安装端的dpkg也没有； Perl主要用于dpkg-dev开发环境，即构建软件包时。
啊，抱歉。我必须承认对Debian打包流程中不同工具与组件的边界划分并不完全清楚。
我确信Debian基础系统完全不包含GUI组件。
> 特别是解析.deb、.ar、.tar文件的代码，以及HTTP签名验证代码，若采用内存安全语言将显著提升安全性
> 关键基础设施仍使用C语言编写——尤其是处理不可信来源数据的代码——这已成为技术债务，且随时间推移只会恶化。
但这些基础代码在过去30多年里不早就稳定且经过充分测试了吗？.tar和.ar格式都诞生于70年代；将这些经受过充分实战检验的代码抛弃，用全新语言重写并引入整套兼容性问题和漏洞，用户或开发者能获得什么新收益？
我当然希望如此，但这些组件几乎每年都会出现新的安全漏洞。公平地说，并非所有漏洞都会通过安全更新追踪修复——有些漏洞我们甚至会告知用户：“若你用该库解析不可信代码，那只能怪你自己。”
毕竟该库的设计初衷并非安全导向，我们默认用户提交的.deb包具有某种可信度——因为它们要么发布在官方仓库，要么即将安装(此时本就附带root维护脚本)。
但随着托管站点和PPA等服务兴起，运维人员开始为非可信用户发布deb包，这突然形成了某种安全边界，导致这些漏洞变得棘手。
当然内存安全只是其中一环，若存在单进程为多用户发布仓库的情况，程序崩溃还可能导致拒绝服务攻击，但这已比潜在的代码执行漏洞有所进步。
我预计重写代码将力求与原版完全一致以避免引入新漏洞，随后再为其添加实际的单元测试。
“人算不如天算。”
> 但这些基础代码在过去30多年里不早就稳定且经过充分测试了吗？
未必。所谓“HTTP签名验证代码”听起来涉及密码学，而我观察密码库维护者的经验是：这类“基础代码”往往是让人尖叫着逃离的领域。总体而言，我注意到密码学领域正是推动迁移至Rust的最积极群体。
至于其他类型的解析代码，各类归档文件格式基本不再演进，因此更新必要性不大。但另一方面，这类领域恰恰存在关键基础设施——它们过去和现在都极少投入对抗性测试，因此无法确定其历史悠久是否真的筛除了安全关键漏洞。正如OpenSSL存在一个可轻易利用的高危漏洞长达两年才被发现。
真正的密码学代码，最佳方案是采用形式验证的加密算法实现；而OpenPGP或PKCS#7等封装格式的解析器则应使用内存安全语言编写。
当存在经形式化验证的汇编版本时，你绝不该为追求Rust而用Rust实现核心密码学。形式化验证方案永远胜过其他任何方案。
我本应说明，我主要指的是处理各种封装格式(如PKIX证书验证)的内容，而非核心密码算法本身。
在我看来，核心密码算法应当采用专为编写密码算法设计的语言实现，这样就能获得经过形式验证的常数时间汇编代码，而无需抱怨我们编译器作者总在研究如何破解其分支结构。
确实。但汇编实现本质上缺乏可移植性。虽然我不清楚编写此类形式验证库的具体成本，但想必极其高昂。
反观Rust实现，既能轻松编译至多种架构，其内置安全性又远超C语言版本。
更何况密码学与PKI领域持续演进，无法沿用数十年前的成熟实现方案。
> 形式验证方案永远优于其他方案。
若采用冷门语言实现形式验证，导致难以招募维护者，其价值便不及用更“主流”语言编写的方案——即便后者尚未通过形式验证。
而如今(遗憾的是)我认为汇编语言也属于“冷门语言”范畴。
(无论如何，我认为Rust版本的密码学原语仍会包含针对不同平台优化的内联汇编，或至少会使用编译器内置函数——虽然比汇编安全，但仍非绝对安全。)
涉及密码学时，你真的应该直接编写汇编代码，因为高级语言根本无法保证所需的精确时序控制。
这极其复杂，尤其当你需要可验证的加密方案时。去年(或前年？)我曾修复过OpenSSL中ARM汇编代码的微小拼写错误，这个漏洞导致APT和Postgres频频崩溃，但仅在AWS环境触发：D
我渴望存在一种专为编写密码代码设计的特殊语言，确保恒定时间算法始终可用。在这种利基语言中，“我们发现Blemvich-Smith算法提速20%——哎呀，在Arrow Lake微代码18至46版本上它其实并非恒定时间”这类问题连夜间构建都进不去，更别说正式发布了。
不知为何，这个想法似乎并不受欢迎，人们反而热衷于手写汇编代码。
已有不少尝试，比如RobustIsoCrypt或FaCT：
https://github.com/PLSysSec/FaCT
它们难以保证在非恒定时间应用中实现子程序的恒定时间执行，而这恰恰是多数人使用密码学的方式。
你无需将整个程序用汇编语言编写，只需将需要恒定时间执行的部分用汇编实现。即使这些部分也最好写成从主实现调用的子程序。
以BLAKE3为例：关键部分采用汇编实现，而最常被读取的结构化组件则像参考实现那样用Rust编写。
确实如此。
我认为这确实是真正“可移植汇编器”的唯一用例——它本质上仍是汇编语言，但编译器会自动完成寄存器分配和指令选择(例如避免处理add32 y, x, 0xabcdef这类因常量过大而无法编码的指令)。
面对NASA那种十进制数量级的限制，难道无法规避吗？
若指GnuPG，这正是斯诺登使用的工具。它可能比可能存在新漏洞的新软件更可靠。内存安全在密码学安全性中仅占极小部分。
(新型加密软件可能由各种人员开发。此处我虽不熟悉具体情况，但我们确知GnuPG在最高关注度的案例中经受住了考验。)
若按开发者初衷手动加密/解密邮件，GPG表现优异。PGP/GPG算法从未设计用于API或网页界面。
讽刺的是，正是“避免自研加密方案”的冲动，导致人们陷入GPG相关的安全漏洞。
根本不存在。这是某个正统派员工试图将Ubuntu的决策(Rust核心工具)强加给更广泛的Debian社区。
此外，这种态度显得如此尖锐刺耳，恰恰符合Rust在线传教士的典型风格。
> 但这些基础代码难道不是在过去30多年里已经稳定且经过充分测试了吗？
并非如此：不到5年前就出现了CVE-2020-27350漏洞，这是tar/ar实现中的内存安全缺陷。
但就在今年，tokio-tar库又曝出CVE-2025-62518漏洞。
所有软件在被发现漏洞前都看似稳定可靠。
最近Rust核心工具包出现了一个漏洞，导致Ubuntu的自动更新功能基本失效。:)
看到Ubuntu员工发出的这则毫无觉察的声明本该令人发笑——要不是我自己正在使用Ubuntu的话。看来我得纠正这个状况了……
更讽刺的是，所有这些操作竟出自同一个人之手？
不过说真的，请放心，我计划以极具同理心的方式处理APT中的Rust支持。相较于用Rust重写整个APT系统，直接在现有APT框架中集成Rust的最大优势在于：我们能审视自身代码并直接迁移，从而避免重蹈历史覆辙。
你向来不擅长体贴入微：
https://github.com/keepassxreboot/keepassxc/issues/10725#iss…
天啊这处理得真糟糕。
说实话，过去十年看着Canonical接二连三制造灾难性事件，我确信不止我一个人对相关人员能否“避免重蹈覆辙”或改善现状抱有强烈怀疑。
这想法挺合理。真希望你当初在原帖里就这么写。祝你好运……
Fil-C项目(https://fil-c.org/)似乎是处理老旧用户空间代码中C语言安全漏洞的更务实方案。它实质上将C语言转化为受管语言而非裸机语言，似乎消除了大量重写的动力。
我非常赞同Fil-C降低遗留代码风险的理念，但
– 除非它至少支持与Debian核心基础设施相同的架构(如ARM、RISC-V等)，否则无法成为Debian核心基础设施的选项——目前它仅支持x86_64。
– 它并未使C语言现代化，鉴于当前存在活跃的C语言现代化开发，摆脱C语言获得生产力提升的价值依然值得追求。
既然C语言尚未消亡，仅针对x86_64实现Fil-C仍可能带来重大收益——它能在运行时为x86_64用户捕获大量问题，进而修复所有平台的缺陷。
考虑到同期诞生的若干语言至今仍在使用(即便用户减少)，只要当前计算模型保持相关性，C语言必然持续存在。
若仅支持单一平台(Fil-C仅限x86-64架构)，程序开发已完成(Fil-C并不能神奇地简化C项目的维护工作)，且性能无关紧要(Fil-C注定比现有方案更臃肿低效——尽管其创始人信心满满)，那么我认同此观点。
让核心包基础设施慢10倍似乎不太务实。
作者的基准测试表明10倍慢只是病态情况！
但即便如此——正确且安全的软件代价几何？当初应用首个Meltdown和Spectre修复方案时，我们一夜之间损失了海量性能。这似乎没什么不同。
我们已有替代方案(Rust)，既不存在10倍性能损失，还具备诸多优势。唯一代价是放弃对某些极其陈旧且冷门平台的硬件支持。(更别提Fil-C的硬件支持范围比Rust更窄。)
Rust无法自动为现有C代码添加内存安全保障——这些代码仍需维护数十年，而Fil-C几乎能做到，且尚处早期阶段。
> 我们有替代方案既不会慢十倍，还具备诸多优势
任何参与某水果公司开发项目的人都会说Swift 😉
我感觉Swift团队对OS X和iOS之外的应用场景兴趣有限。(此处背景是Debian系统。)
目前似乎有推动Swift走出苹果生态的趋势，主要体现在Linux和Android支持以及后端微服务开发领域。
这不仅关乎内存安全。C语言社区正快速老化，年轻开发者正转向其他语言。我们团队已开始重写所有C和C++代码，因为实在难觅愿意维护这些代码的人。根据我的经验，典型的C或C++程序员年龄多在40岁左右，且不愿转换职业。
邀请毫无经验的新手加入成熟项目，却指望他们免费劳作以换取未来就业机会，这种做法令人感到别有居心。结合评论内容来看，原帖这类言论简直是在利用年轻一代的迫切需求。
倘若所有入门岗位都要求C或C++技能，你认为企业真会招不到人吗？若Rust不在选项中，失业的应届生们当真会拒绝这些有偿工作机会？
与此同时，招聘经理们纷纷反映，职位发布后短短数小时内就会收到数百份申请。可你们却因技术栈的编程语言找不到合适人选？为解决这个问题，竟打算用未经验证的语言重写技术栈？可曾想过，找不到人选或许并非编程语言或技术栈的问题？
我用C++工作的经历是薪资不如其他领域。这才是我离职的主因，并非厌恶这份工作。
哇，我从未考虑过这个角度，但你说得对。若想广泛招募能为项目贡献力量的新开发者，当前若追求底层语言，无论个人偏好如何，默认选择确实只能是Rust了。
可惜银行当年没对COBOL这么做…
他们确实这么做了，Java和.NET就是例子。
你那儿薪资待遇如何？Rust岗位本就稀缺，我猜Rust信徒们愿意接受较低薪资来用梦想语言工作。当然公司会趁机压榨。
我同意新软件应该用Rust或其他更安全的语言编写。但我不认同用这种方式改造 旧 软件是明智之举。新代码的质量几乎总是逊于旧代码，我不认为Rust带来的安全性优势足以抵消这个劣势。
那么逻辑上是否也应将Python和Ruby这类依赖C语言的语言(后者本质上是基于C语法的语言)视为技术债务？
是的，正因如此，在2025年为性能敏感代码采用Rust搭配Python绑定方案是明智之举。
Python中大量C代码调用的都是久经考验的利基类库，短期内无人会替换它们，但Rust在绿地项目中的应用正持续增长。
依赖C语言的Python库大多属于数值计算类。
根据此类代码的经验，通常会出现大量函数：它们接收numpy数组及其长度/维度参数，调用C函数对该数组进行原地操作，或处理用户提供的输出数组。这类操作出错时，通常会因越界访问内存导致崩溃——在Rust中这仍属于运行时错误。因此除却学习Rust的乐趣，此类代码未必能获得显著优势。更何况，我们编写C/C++代码主要是为了对接久经考验的C和Fortran库，而Rust要开发出同等成熟的替代方案尚需数十年。因此转向Rust只会导致大量不安全语句——若需在现有代码中进行大量C级操作倒非坏事，但若只是直接封装库则收益有限。
反观Python的Web生态，像用C语言编写的uWSGI这类组件虽对安全性至关重要，但它们在Python生态中占比极小。
并非如此。
所有(现存)语言最终都存在内存不安全的编译器/运行时环境。这基本不成问题，因为其影响范围极小(相对于使用它的代码总量)，且输入数据相对良性，因此有足够的人力/时间/…来发现漏洞。
况且当提升计算机可靠性成为低垂果实时，你完全可以重新实现更安全的Python/Ruby等语言。
> 基本没问题
动态语言引擎里出现过多少次类型混淆漏洞和内存安全问题？我都数不清了。
你知道CPython里有多少种不需故意篡改字节码就能引发段错误的方法吗？
“类型混淆”如何构成安全问题？
你指的是在沙箱中执行恶意代码的情况，还是仅限于可信代码处理不可信输入？如果是后者我同意，但那完全是更复杂不同的问题。
我印象中，可信代码处理不可信输入的案例并不多见，但可能记错了。
这取决于沙箱用什么语言编写的？
沙箱的实现难度与语言无关，看看最近那些推测性漏洞就知道了。当然，糟糕的语言会让沙箱更难实现，但讨论沙箱本身已偏离了“python/ruby”的初始议题。
> Rust的设计理念是：假设我们以当今对语言设计和代码安全的认知来重构C语言，最终会得到这样的结果。
我不确定。例如，看看COSMIC桌面环境时钟小部件的代码(位于https://github.com/pop-os/cosmic-applets下的cosmic-applet-time目录)。相比同等复杂度的C代码库( 例如GNU核心工具集：https://savannah.gnu.org/projects/coreutils/ )，它的代码简直难以阅读。
我认为这是你的问题
即“不符合你习惯的编码风格”
“陌生人能否读懂”对多数语言而言并非有效评估标准。
此外依我之见，C语言看似可读却在关键时刻失效——它常省略阅读所需的关键信息。比如函数头部无法说明指针是否可为空，也无法说明mut指针是可变输入值还是out指针(后者本应指向未初始化内存)，更无法说明错误发生时如何影响传入可变指针的有效性状态。以上仅举几例(更别提伪装成C函数的预处理器宏了)。总而言之，虽然C语言代码读起来很顺眼，但在我看来，“正确”阅读它(比如在代码审查中)往往是个痛苦的过程。
附注：例如
chrono::DateTime看似冗长的语法，源于该模块同时使用两种DateTime类型——一种来自国际化库(icu)，另一种来自通用时间库(chronos)。Sender等类型亦是如此。这虽非普遍问题，但确实偶有发生。我认为Rust示例最大的可读性缺陷在于使用foo::bar::Baz这类全称而非简写Baz，但理解其设计初衷。当文件导入大量模块时，后者易引发“这是foo Baz还是wiz Baz？”的混淆。有时全程使用长名称反而更明确。
若要修改这个Rust项目，我能确信自己调用的参数都准确无误。
这种风格选择源于C++开发者的习惯。
Java理论上可能存在相同问题。但由于普遍使用IDE且实际冲突罕见，开发者通常直接导入
Baz而非纠结Foo::Baz与Bat::Baz的命名冲突。Java代码中确实存在这种情况，但我必须强调这几乎不会成为实际问题。我认为这种说法不太准确。虽然我90年代后就没写过C++，且使用Emacs和Zed等IDE，但有时仍会达到心理临界点——当屏幕上出现超出记忆缓冲容量的命名时，我就会主动选择更明确的命名方式。
不清楚Emacs/Zed在类型信息方面的实现(肯定取决于具体语言)。但在Jetbrains/Eclipse/Netbeans中，遇到类型疑问时只需Ctrl+点击类型名，就能立即获取完整信息。
在Java开发中，我几乎不关注
import语句(公司多数开发者亦如此)。搜索
using namespace std;会发现大量文章指出这是C++中的不良实践。所有人都建议使用完整写法std::cout而非简写cout。如今所有现代编辑器借助语言服务器都能很好地实现这点。特别是Emacs和Zed在处理Rust时表现完美。
我认为这终究取决于个人偏好。使用全限定名时，我只需看屏幕就能追踪流程，无需鼠标悬停在各种变量名上。更何况，即使打印代码也能保留所有信息。
我认为你并非客观错误，只是我们处理复杂情况时采取了不同方法。
遇到名称冲突时，我直接用唯一名称导入——比如Wiz_Baz和Foo_Baz
这根本是风马牛不相及的比较。
该模块大部分代码用于GUI维护，涉及时间处理的部分完全清晰可读。
> 几乎完全不可读
我不同意。只要了解其首选编码风格，两者都完全可读。作为非C语言程序员，我极度厌恶遇到#ifndef SOME_OBSCURE_NAME和
while (n) { if (g) {这类写法，但C语言(以及后者的Go语言)程序员似乎偏爱这种风格。将一堆小型、几乎无法整合的命令行程序与用户界面+日历小部件相比较，在我看来并不算“复杂度相当”。观察C语言时钟小部件(https://gitlab.freedesktop.org/xorg/app/xclock/-/blob/master…)，两者差异在我看来微乎其微。当然，XClock代码不涉及日历功能，因此还需额外考虑相应的UI代码实现。
https://cgit.git.savannah.gnu.org/cgit/coreutils.git/tree/sr…
恕我不敢苟同。
大部分复杂性源于处理支持本地化日期格式的系统。其他多数'date'实现并未做到这一点。
最直观的体现是美国区域设置：GNU 'date'采用12小时制，而其他实现则不然：
我最近为此添加了测试用例，因为这是项实用的功能[1]。
[1] https://github.com/coreutils/coreutils/commit/1066d442c2c023…
公平地说，在任何两种语言中，GUI代码的可读性都比非交互式工具更差
Rust有点丑。我觉得我更喜欢Zig。
其实我同意。真希望Rust能保留C语言的基本函数语法，我实在讨厌def、fn这类关键字。
得了吧，十年后Rust也会变成技术债务，人们会想用Brust之类的新潮语言重写。
Rust 1.0发布已十年，若真会发生这种事，现在早该出现了。但事实并非如此。
但确实出现了…Rust发布四年后，我们初次见识了Zig。时至今日，仍有许多人认为Zig比Rust更适合用于Linux内核开发。
而“为何此时出现”的答案很简单——正是由于整个Rust内核争论，人们开始重新审视现状。
这说不通。比如人们将C视为技术债务，可远不止十年之久。虽不确定是否恰好十年，但我们正见证更优语言的崛起(Swift 6、Mojo等)，它们既能提供与Rust同等的保障性与性能/适用场景，又具备更卓越的易用性与体验。我担心Linux仓促接纳Rust的决定，将阻碍其在近期整合更优方案。
是你自己提到的十年。
是你强调“自Rust 1.0发布十年”的。
没错，那时候Rust还很新潮。但追逐最新潮流的人不会把十年技术视为新潮，他们早就在几年前就弃用它了。
被回复者明确提到了 十年。整件事其实很清楚。
我说的是十年 从现在算起…
C语言已经存在50多年了。没错，我希望五十年后真能有东西取代Rust。
内存安全问题基本属于历史遗留。当然，新代码库也存在内存问题，但我们有工具能预防。如今的新安全威胁是供应链攻击，而Cargo正是解决此类问题的方案。
> 内存安全问题基本属于历史遗留。
能否提供佐证？大量证据表明情况恰恰相反，例如Chrome的案例[1]。
> 但我们已有工具防范此类问题。当前的新安全威胁是供应链攻击。
作为“供应链安全”从业者，此论断站不住脚。供应链攻击 包含 复杂依赖树中潜藏的内存安全隐患风险，二者并非互斥关系。
[1]: https://www.chromium.org/Home/chromium-security/memory-safet…
C语言包管理机制的哪个环节能防御供应链攻击？
它会为你审核第三方代码吗？
我认为关键在于C语言依赖项本身就极为罕见，且添加维护难度极高。
普通C项目最多只依赖几个C库，而Rust/Go/NodeJS项目平均要依赖数百个库。
讽刺的是，正因为现代语言的依赖管理过于便捷，人们才在各处疯狂添加依赖。需要左对齐函数？只需在yaml文件里加一行代码，或在IDE里按下Alt+Enter——搞定。
用C语言？那工作量可大了。若真要这么做，也只适用于项目中绝对必需的高级功能。毕竟这绝非易事。十有八九你得自己编写这些代码。
CVE-2024-3094是吧？可以说在C语言中混淆漏洞利用代码要容易得多。用C语言实现功能同样耗时费力，因此你可能更倾向于使用第三方库。
我从未觉得用pkg-config向项目添加C库有多难。而且确实，当软件包来自Debian时，我对其供应链风险的信任度较高。
我认为问题根源在于那些语言级管理工具——它们本质上只是GitHub代码仓库集合，而非经过精心维护的发行版级包管理器。因此我对“C语言缺乏优质包管理器”的回应是：它本就不该有包管理器，Cargo、npm乃至无数Python管理工具都该不存在。
但pkg-config并非难点所在，对吧？
C库真正的难点在于依赖链中的多重依赖，它们各自采用复杂的构建系统——Make、CMake、Autotools、Ninja等混杂并存。
更棘手的是，构建参数命名体系混乱：既存在标准命名规范，又混用如PROJECTNAME_COMPILER而非CMAKE_C_COMPILER这类非标准格式。
包管理器会自动处理依赖关系。用户无需编译所用库，因此复杂程度无关紧要。安装-dev包即可搞定。这种机制运行良好，若出现问题，正确做法是修复它。
在我多数项目中，工作所需的C++软件包(如计算机视觉、视频编解码器等)往往需要自行编译托管。OpenCV、dlib或gstreamer等最新版本在常用发行版(Ubuntu/Fedora/Centos)上根本找不到，有时甚至滞后一年以上。有些软件甚至完全无法通过包管理器获取——任何版本都找不到。
因此，你确实经常需要自己摸索如何构建和打包这些软件。C语言中也不存在“leftpad”这类现成包，除非你愿意自己编写。
相比之下，cargo或npm几乎能提供任意版本的软件包。
几乎所有软件包都存在于 cargo 和 npm 中，正是因为缺乏内容审核机制。这恰恰构成了供应链风险。解决之道是建立审核过的软件包清单，而这正是 Linux 发行版的本质。没有捷径可走。
正如GvR在2011年著名提醒的那样，语言与打包系统是两回事。
但Rust，你知道的，它 自带 打包系统。
不。Rust并非魔法，它只是强制实施了某种纪律，使特定安全检查得以自动化(或完全免除)。在C等语言中，程序员必须手动执行这些检查；若C代码未经过谨慎编写和安全审查，便会形成技术债务。若编码严谨且代码经过审查——则不存在技术债务，或者说其程度不会超过Rust代码库中不安全部分或标准库的风险。随着技术债务的逐步偿还，用C编写的关键基础设施代码安全性会随时间推移而_提升_。
> Rust的明确设计理念是：若以当今语言设计与代码安全认知重构C语言，其形态当属此类。
此论断并不成立。首先，所谓“当今认知”始终存在争议与多元观点，该表述缺乏严谨性。但即便抛开这个争议——C语言本身就具有特定的设计选择和美学取向。Rust在_任何方面_都不共享这些选择——即使附加“且必须安全”的条件。例如：Rust在语法、基本类型和标准库方面都远比C语言设计初衷更为丰富。
> 若编码谨慎且代码经过审查——便不存在技术债务，或者说其程度不应超过Rust代码库中不安全部分或标准库的风险。而用C语言编写的关键基础设施代码安全性会随时间推移而提升，因为这类技术债务正被逐步偿还。
我们尝试这种方法已有多少年？还要再等多少年才能发现事实与你描述的截然不同？
> 若编码谨慎且代码经过审查——便不存在技术债务，或者说其程度不应超过Rust代码库中不安全部分或标准库的风险。
历史反复证明这种说法根本不可能成立。
随便举个广泛使用的大型C应用程序，我就能指出至少一个由该项目内存泄漏引发的CVE漏洞。
[已删除]
虽然我理解你的观点，但我认为举例说明能让讨论更具建设性地推进
> 事实就是它更优秀，对吧？
看到大家明白这点真酷！
如果人们真的、真的想让所有基础设施都用Rust编写，就该挺身而出停止使用LLVM。
纯Rust编译器后端正在开发中，但成熟需要漫长时间，因此过渡期使用LLVM是务实之举。尤其考虑到此处的漏洞利用场景相当牵强——若编译的代码已被植入恶意代码，无论后端内存安全如何，系统很可能早已被攻破。
对LLVM的担忧何在？我真心不明白。
我认为他指的是：LLVM本身用C++编写——这意味着整个“可信”的Rust工具链，本质上依赖于信任一个庞大的C++应用。
所幸编译器所需的“信任”性质截然不同。这更像是要求必须在Rust操作系统上编译，因为你正在信任一个庞大的C/C++应用程序。
关注点分离解决了这个问题，因为编译器对Rust编译器生成的代码可信度影响微乎其微。事实上，LLVM编译器可能失败的所有方式，任何Rust实现都可能同样失败——即生成错误代码，而这种错误极少(甚至从未)源于内存安全或线程安全问题。编译器后端采用Rust可能有其他理由，但我不认为对编译后Rust代码的信任度应成为首要考量。
我认为由于其采用不安全的C++编写，必然产生技术债务，应尽快解决。
他们需要谨慎操作并进行对抗性测试。例如gnu tar中的安全措施确实值得借鉴，但这些措施与解析无关，而是涉及语义层面的保障。
换言之，你们的规范是什么？
> 难道Rust比C语言难写多少吗？
依据什么？
> Rust是经过精心设计的
根本不存在标准。它只是偶然形成的产物。
> 基于我们对语言设计和代码安全的现有认知
你只是解决了“unsafe {}”之外的一类漏洞。其余问题依然存在。
> 根本不存在标准。这只是偶然的设计。
你当真认为没有官方标准就无法设计语言？更别说C语言早在首个ISO标准出台前就已成型。最后必须指出，将标准委员会视为优秀语言设计的先决条件，这种观点未免太过大胆。“委员会设计”这个说法通常不是褒义词…
> 你解决了一类“不安全{}”之外的漏洞。
这“仅仅”是系统安全中最关键的漏洞类别。
这种转移话题和否认态度毫无帮助。而我是真心喜欢C++的人。
> 难道没有官方标准就无法设计语言？
并非如此，只是时代已非1968年。若宣称语言吸取了历史教训，这显然是个被忽略的教训。
> “委员会设计”这个词通常不作褒义…
而“突发性不兼容”这个词本身就是个贬义词。
> 这“仅仅”是影响系统安全最重要的单一类错误。
再次要求依据：“依据什么？”我明白这是时代思潮，但事实是否如此？在我看来，这场伟大实验正在证明它可能根本不成立。
> 这种转移话题和否认态度毫无助益。
我再次要求证明该论断的真实性，你却毫无依据，反而将自身缺陷投射到我的论点上。
> 作为一名真心喜爱C++的人，我必须指出：
你可曾因某些模糊且从未量化的标准，就主张用C++取代C程序？
啊，现在我明白你未必指的是ISO标准之类的东西。我完全认同编程语言应当具备规范性标准，仅说“编译器的行为即为规范”是不够的。
> 我再次追问依据：“依据什么标准？”我明白这是时代思潮。
我认为当前已基本确立：C/C++应用程序中多数安全漏洞(CVE)源于内存安全缺陷。相关来源参见https://www.cisa.gov/news-events/news/urgent-need-memory-saf…。作为C++开发者，这完全合乎逻辑。(我恰好从事的安全性无关领域工作 🙂
需要明确的是：我绝不认为所有C或C++代码都该重写成Rust。但对于暴露在公共互联网中或接受不可信用户输入的组件，这样做完全合理。
请问这个领域具体是什么？
音频与多媒体艺术。
谢谢
遗憾的是多数人并不认同
我长期观察到这个论坛对Rust的敌意。起初完全无法理解，直到真正尝试学习才明白这种抵触情绪的根源。
它确实难到令人望而却步，多数人可能永远无法精通。即便尝试学习也困难重重，尤其对来自内存管理语言背景的开发者而言。这导致任何推广Rust的行为都会遭遇抵触——人们似乎隐隐担忧，若Rust普及，自己将被时代淘汰。
我已结束与Rust的较量，如今甚至不再使用它(因缺乏实践机会)。但我热爱Rust。它注定会持续发展壮大，这得益于大型语言模型(LLMs)的兴起和可验证性需求的增长。
我发现Rust比C语言更易编写。其类型系统让我在运行测试前就能合理确信代码正确性，且无需记忆整个程序流程即可获得这种保障。
例如：
此代码在构建时报错：
确保从不混用单位意味着我无需担心将航天器停泊在预期高度的1/3处。现在我能专注于其余逻辑。语言在类型方面为我保驾护航，让我永远不必浪费脑力处理繁琐的记账工作。
这只是一个例子。它绝非Rust独有。但相较于C语言仍是巨大进步——在C中同一个32位有符号数据类型可能同时代表篮子里的鸡蛋数量、结构体中的字节偏移量、数组索引、UTF-8码点等等。
重构时这种优势尤为明显。移动Rust代码时，它会明确提示你需要修复的内容才能继续。C语言？可没这么贴心。
你只是向函数传递了类型错误的参数。完全相同的代码在C中会编译失败：
对于动态类型语言(如Python)的用户，这或许令人耳目一新，但自计算机编程诞生以来这已是老生常谈。C语言服务器会在编译前检测到此问题，正如`rust-analyzer`所示：`参数类型“Feet”与参数类型“Meters”不兼容`。
你难道不知道吗？我感觉论坛上很多批评C语言的人根本不清楚这会导致编译失败，而且IDE还会提前提醒你…
人们使用头文件库，是因为他们把C和C++这类语言当作脚本语言来使用。
没错，而在C++里你还能用到超棒的零开销单位库
这例子不太恰当。将整型值封装到结构体中，在C语言和C++中的实现完全相同(参见https://stackoverflow.com/questions/40629989/pros-and-cons-o…)
C++还能通过重载运算符让这类结构体的数学运算更符合人体工学。
编译器理解这种惯用手法，会优化掉结构体。
这本可拯救火星气候轨道器：https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
> 调查报告指出，此次失败源于两种测量系统之间的单位不匹配：NASA采用的国际单位制(公制)与航天器制造商洛克希德·马丁公司使用的美国习惯单位制[3]
这只是直接原因，根本原因在于文化因素。当复杂系统和项目遭遇问题时，将责任归咎于单位换算实属轻率——毕竟他们数月来始终无视相关人员的警示[0]
地面控制人员连续数周甚至数月忽视了一系列表明飞行器轨道存在严重问题的迹象。但管理层却要求忧虑者和质疑者“证明存在问题”，尽管根据任务安全的经典基本原则，当存在重大疑虑时，他们本应主动确保飞行状态“万无一失”。
NASA内部人员失职同样存在问题，但真正导致实际坠毁的根源在于文化问题。
[0] https://spectrum.ieee.org/why-the-mars-probe-went-off-course
从技术层面讲没错，但如果NASA的API接受米制单位参数而非int32_t(或其使用语言的等效类型)，洛克希德·马丁编写的控制器代码使用错误数据类型的问题就会立即暴露。
我们是否清楚代码调用方式？是通过链接调用还是IPC调用？(后者可能性更大，关键在于IPC框架是否支持丰富的类型系统)
这正是我撰写该内容时的考量。
但请注意，有多少libc函数会以不同顺序接收多个整型或字符型参数。过度追求类型化可能适得其反，比如为所有元素都定义独立类型。但设想你正在编写某个假想的IDE设备驱动程序，为BlockNumber和ByteInBlock分别定义独立类型，这样就不可能将read(byte_offset,block)误写成read(block,byte_offset)——即使它们本质上是同类数值。
这种设计能让无数错误直接消失在虚空中。
虽然略显笨拙但更稳妥的做法是：
ide_read ( &(struct ide_loc) { .byte_offset = 10, .block = 20 } )
我常思考相关问题：假设某个函数有 n 个参数且类型各异，是否应强制程序员按特定顺序传递参数？这本无歧义。
不同便利性之间似乎存在某种张力。若采用 read(offset: 读取偏移类型, address: 读取地址类型) 的形式，就能捕捉到有人误将地址传入偏移位置、或将偏移传入地址位置的情况。
或者，你可以声明“嘿，我总是将偏移量加到地址上；传入顺序无关紧要”，从而免除程序员记住两个语义不同的变量传入
read函数时顺序的负担。但若提供这种便利——这完全符合直觉； 因为地址与偏移量的组合无论顺序如何，实际只有一种有效解释——你将失去类型系统本应提供的部分安全性保障。若变量声明无误则一切正常，但若声明存在错误，那些本应被捕获的错误调用将被放行通过。
咦，这观点很有意思，我得好好琢磨。仍有许多场景依赖顺序，比如
subtract(a,b)，除非彻底定义为：但这似乎有些冗余。你的想法在其他场景仍很有用——比如我总记不清Python中是json.dump(file, data)还是dump(data, file)。归根结底，这重要吗？我传递的是文件句柄和对象，两者与当前任务的关系本就明确无误。
你的方案如何处理米每秒和秒的转换？
据我理解，Rust 不会允许你进行类型检查的 m/s * s => m 转换，因此利用类型系统玩这种把戏既愚蠢又危险(我猜你只能做蠢事进行类型转换——例如：
这意味着你在代码中到处插入非科学且易混淆读者的类型转换)
在Rust中这不成问题。你可以定义 Speed 类型和 Time 类型，并为它们定义乘法运算符，使其返回 Length 值。事实上已有库实现了此功能，并预定义了大量SI单位：https://docs.rs/uom/latest/uom/
C++同样能实现完全相同的功能。
我非常困惑，请解释为何C语言不具备此特性？
我虽未编写过Rust代码，但印象中其优势更多在于对生命周期等概念的深度内省，而非基础类型安全——后者在C/C++中早已存在(且同样常为便利而被绕过，因此我好奇Rust中是否也存在类似情况)
相关库 Sguaba [1] 由 Jon Gjengset 编写，出自 Helsing AI，它允许你在类型层面上定义坐标系，并实现基于这些坐标系的安全转换与计算。
[1] https://github.com/helsing-ai/sguaba
我超爱这种设计。当API几乎不可能被误用时，实现合理结果就变得轻松多了。“该死，它逼我把摄氏度强制转换成米制才肯调用这个函数。等等，这不对劲啊…”
在C语言里这会直接报错，你这是在说什么？
C语言的结构体同样具备类型安全特性。
才怪，是你技术不够好。比如我用C语言调用hover(int32_t)时就绝不会犯这种错误。就算万一搞错了，我的代码审查员也会发现这么低级的失误——毕竟他们同样是顶尖的C开发者。
/s
我的下巴不自觉地紧咬起来。
> 尤其来自内存管理语言的世界。
若这类人抱怨Rust，我绝对不愿让他们碰C代码库。
内存管理语言本身无错，只要你无需操心内存管理。但既不懂内存机制，又抱怨那些帮你避免自掘坟墓的机制，实在令人难以信任。
即便转学C语言，学习Rust的艰辛也不会消失。结果只会是写出漏洞百出的代码，并逐渐将这种艰辛与根本问题——内存管理——联系起来。
> 它确实如此艰深，多数人即便尝试也可能永远无法精通
若以“代码质量需达Debian收录标准”为衡量基准，我认为C语言比Rust更符合此描述
在我看来，任何具备编程能力且愿意投入足够时间的人都能掌握Rust。
有些人可能需要数月而非数日，但我认为这是理想的结果。
重要的底层软件应当由愿意付出努力的合格开发者编写。
精力更应投入到学习底层硬件工作原理，以及为系统引入冗余和可观测性上。
这完全是牵强附会。
核心问题在于C语言过于基础陈旧，缺乏完善的高级抽象，导致编写健壮安全的软件格外困难且耗时。“学习底层硬件”根本无法解决这个问题。
Debian支持数十种架构，因此必须 抽象化 掉架构特有的细节。
Rust在软件优化方面赋予你与C语言同等的控制权，但同时Rust和C都刻意避免暴露底层硬件细节。它们针对的是具有“未定义行为”的抽象机器，其行为模式与硬件不同。若你以为能直接复现硬件行为，优化器会让你吃大亏。即便你能直接编写硬件中每个逻辑门的指令，也无法解决编写安全解析器和正确包验证逻辑时面临的脆弱性与枯燥性。
假设你关于该语言对多数人而言过于艰深的观点正确，根据计算机发展史，我预料的结果是该语言将失败或困守利基市场
屡屡胜出的总是那些理论上更差却易于获取的方案
> 它确实如此艰深，多数人即便尝试也可能永远无法精通。
这同样适用于C和C++……
我曾是(至今仍是)C++开发者，却不知不觉也成了Rust开发者。我确信有人会感到被冒犯，但在我看来，Rust继承了C++作为优秀语言的核心特质，因此我选择“拥抱”Rust而非视其为威胁。
没错，Rust并非C++，但它与C++相得益彰。二者各有专长，坦白说我更看好它们在系统领域形成双雄并立之势，而非真正相互竞争。
若有人将STL诞生前C++因缺乏命名空间而产生的各种黑客式 hack 方案，与现代C++特性混为一谈视为C++社区的组成部分，那我可就大吃一惊了 😀
倘若APT是个硬核C++项目，我们早该全面采用命名空间了。
> 我认为任何由自诩为“X派人士”(如Python派、Perl派)主导的项目，面对新语言加入其项目时，总会产生些许“反感”——毕竟他们视项目为语言社区的一部分。
我认为Python开发者对“(其他)语言加入”Python生态系统早已习以为常。毕竟NumPy既依赖Fortran也依赖C语言。
这种对代码宣称“所有权”的做法在我看来相当令人反感。或许如果开发者能因此获得报酬，争议会少些。
> 假设你是位C++开发者，多年来为APT贡献代码，目睹所有成果都与C++社区紧密相连(你也是其中一员)，此刻有人想将部分代码迁移至Rust/$NewLang。我认为这对这类开发者而言，影响可能远不止代码层面，甚至可能(用词或许偏激)触及他们的身份认同感——无论这种认同感是积极还是消极的。
语言在此有何关联？若有人用相同语言而非新语言重写，你认为反应会好得多吗？
这确实是Rust特有的现象，因为大量C++项目被逐行翻译成Rust，仅更换了许可证。
Rust已成为窃取GPL3开源项目的常用工具——这些项目往往凝聚着开发者毕生心血。
后续讨论中有条消息值得关注：https://lists.debian.org/debian-devel/2025/10/msg00288.html
> 除alpha、hppa、m68k和sh4(未提供sqv支持)外，Rust已成为所有Debian发布架构及端口的强制要求。
那么这对这些架构意味着什么呢？
还有人用这些机器吗？真心求知，非恶意挑刺。
各架构最后发布的机器时间如下：
Alpha架构：2007年
HP-PA架构：2008年
m68k架构：2000年前(衍生架构仍用于嵌入式系统)
sh4架构：1998年(可能通过“J2核心”使用过期专利实现)
这意味着多数架构已近二十年历史。
Rust支持的目标平台三元组包括：
m68k：https://doc.rust-lang.org/nightly/rustc/platform-support/m68… 及 https://doc.rust-lang.org/nightly/rustc/platform-support/m68… 均位于第三层。
(其他目标未找到对应三元组。)
如果你在使用这些机器，它们的用途是什么？(再次强调，纯粹出于好奇)
Debian刚砍掉了i386架构，维基百科显示i386早在2007年就已停产。这些系统都属于同一时代产物，因此从支持列表中移除似乎并非突兀之举。
[0] https://en.wikipedia.org/wiki/I386
实际的 Intel 80386 处理器确实在2007年停产，但i386架构——即ia32、32位x86——在半主流领域延续更久(32位Intel Atom处理器直至2012年仍在上市， AMD Geode系列至少销售至2019年，据信部分威盛C3/C7衍生产品也延续至2010年代)，事实上至今仍在嵌入式及工业市场持续生产(如Vortex86等)。
这些都是i586或i686架构吧？AMD Geode LX是过去15年唯一生产的i586处理器。
其余均至少支持i686，而Rust对i686的兼容性完全足够。
还有主流发行版保留i686之前的架构支持吗？
据我所知，Debian的i386实为i686架构。
我们仅停产了i386(32位)处理器，但64位处理器仍可运行32位模式。因此工具链依然广泛可用，且存在对i386操作系统的需求——这类系统能在现代硬件上以i386模式运行古老软件。
没错，现今常见的amd64处理器仍可运行i386二进制文件。这更强化了淘汰其他过时平台的理由。
但运行二进制文件的前提是必须具备对应的libc库。
你说的语气仿佛这比拥有alpha/m68k/sh4硬件更困难甚至相当困难，事实并非如此。
> 还有谁在用这些机器？真心求解，非恶意挑刺。
要么是老旧系统(肯定不会运行当前尖端的Debian)，要么就是复古计算机爱好者。
这些平台早已过时，除了“角落里有台20年没碰过的机器”和“图个乐子”之外，根本没有实际运行理由。我从本地电子垃圾回收站就能免费拿到比它们更强大、更省电的电脑。
这类人通常是吵闹的少数派——要么是网络喷子，要么是业余爱好者。但只需一人就能引发质疑。
这里有个著名案例：某人成功让数十个软件包合并了PR，只为使其兼容古老版本的nodejshttps://news.ycombinator.com/item?id=44831811
哇，这篇读来真有意思。有趣的是，似乎没人真正知道他是谁或动机为何，可他的代码每天却在数百万台机器上运行。
确实存在业余爱好者在使用m68k Mac、Amiga和Atari ST机型。这无疑是个小众领域，而在这类机器上运行Linux的用户更是凤毛麟角。
没错，但几乎没人愿意在这些机器上使用现代Linux系统。他们自己都形容那是“某个陈旧过时的Debian版本”。
相较于Windows庞大的用户群，Linux玩家本就寥寥无几。可人们依然坚持开发游戏。
类似论调适用于无数场景，但显然有人就是喜欢在这里贬低复古计算。
> 考虑到Linux用户基数远小于Windows，没人愿意在Linux上玩游戏。
根据Steam最新调查，3%的玩家使用Linux系统。Steam拥有1.3亿活跃用户，这意味着有400万人在Linux平台游戏。这显然不是“没人”，而且远超整个复古计算机社区的规模。
顺便说一句，我也是复古计算机爱好者之一，我这里就有一台运行Windows 98的奔腾2。我认为，硬要把现代软件塞进老硬件是荒谬的，复古硬件的意义就在于运行复古软件。
> 还有谁在用这些机器？真心求解，非恶意挑刺。
用户群体的相关性本就是个值得探讨的话题。
若仅以用户规模论，Valve大可放弃Linux用户群——毕竟他们仅占总用户量的2-3%。
这并非你的论点，但Linux兼容性是Valve防范微软反复无常带来的生存风险的保障。曾几何时，微软似乎试图让微软商店成为所有软件的分发渠道。Linux在游戏领域的可行性正是他们避免被生态系统封杀的安全网。
Debian用户中使用DEC Alpha架构的比例真有接近2%吗？
人们乐于运行经典软件，在复古硬件上运行现代软件也颇具趣味。
不过这些用户自然能自行维护移植版本
想想任何使用计算机的设备，它们的设计寿命都超过30年。
比如汽车、飞机、工程机械等等。
我敢肯定这些机器没在运行Debian系统。
更不可能运行Debian的下个稳定版本。
为什么？你怎么知道？Debian应用相当广泛啊
它们可能运行Debian，但并非上游的Debian/稳定版
这种情况主要出现在需要认证的系统中
这类场景下仅有C语言规范是不够的，你需要编译器版本特有的规范
类似地，这类系统往往运行相同版本的操作系统，仅回溯安装项目专属的安全更新，而非执行通用系统更新(因每次更新都需要重新认证)
但这需要巨大投入，因此企业根本不愿运行完整操作系统。仅保留内核和最精简的必需软件包，绝不额外安装任何二进制文件。
他们可能选择Debian作为初始软件包和内核来源，但这已非真正的Debian系统
你可能会惊讶。
即便如此，他们也不会更新到最新版Debian稳定版。
只要联网他们就会尝试更新
我的意思是他们根本无法更新，因为端口库里只有不稳定版可用
你错了。人们需要新软件。
若讨论嵌入式控制系统，答案是否定的——你不需要新软件，只需设备按既定功能运行。我们工作场所就有运行VxWorks的老旧VME机箱，没人会把它们升级到最新Linux发行版。
这种观点已过时。互联网连接和第三方集成彻底颠覆了“出厂后软件无需变更”的认知。
约翰迪尔、卡特彼勒等企业正大力推进“互联工业设备”战略。飞机上的GE发动机配备可更新软件，并能将飞行数据实时回传至GE。
嵌入式领域已发生变革。若你仍固守2010年前的产品认知，或许尚未察觉这一转变。
我从事大型科学实验(如粒子加速器)领域，其他领域情况可能不同。但根据我的经验：
控制网络采用空气隔离，严禁任何形式的直接互联网连接。
嵌入式实时系统通常运行VxWorks或RTEMS，而非Linux。若使用Linux，也仅限于NI Linux这类专用发行版。
近15年设计的系统均采用ARM架构。老旧系统使用PowerPC。Alpha、HPPA、SH4或m68k架构早已无人问津。若真想在这些设备上运行Debian，直接用Armbian即可。
不过我认为这些系统不适合/不应通过apt进行更新。
以下是Debian的“受支持架构”列表：https://wiki.debian.org/SupportedArchitectures。这些平台均处于“非官方”状态(即功能可用，但未获Debian核心项目正式支持)。
现在究竟还有谁在这些平台上实际运行Debian Trixie？
令我费解的是，这些平台竟仍被非官方支持，而32位x86[编辑：以及所有MIPS架构！]却未获支持！
看到它们被弃置一旁令人扼腕(甚至莫名想翻出68k Amiga或“古董级Macintosh”尝试运行Trixie…)，但即便从社区角度考量，我也难以理解这些移植版本的实际应用场景。
它们不会被遗弃，我们终将为这些平台提供Rust支持。
只是有些Rust拥趸过于强势，仿佛Rust能解决所有问题，这确实令人困扰。
现在真的能在Amiga或其他68k系统上安装Debian吗？我在网上搜寻过，但没找到太多能证明可行的证据。
这并非针对你或任何参与者——我认为这是个很酷的项目(最近我让86duino ZERO运行了Gentoo，就是想验证这种冷门老硬件能否承载现代Linux——事实证明确实可行)。我完全理解像Debian这样的项目为何不愿为此投入资源，哪怕只是为了降低操作门槛。
这里有篇近期博文，作者尝试在搭载25MHz 68040处理器的Amiga 4000上安装Debian。
https://sandervanderburg.blogspot.com/2025/01/running-linux-…
我没找到他们尝试的具体Debian版本，但应该暗示是近期版本。他们遇到了内存问题——仅有48MB可用内存，而官方建议至少64MB。系统确实能启动，直到因内存限制抛出错误。
不过他们通过尝试Debian 3.1成功运行了系统。
这些系统已有二十多年历史，没人会认真用它们运行现代软件。拜托，放过它们吧。
直到几个月前搬家前，我都在64位SPARC上运行Debian不稳定版，搬家后整理行李时还没重新搭建系统。
它在发现软件怪异边缘案例时颇有价值——某些问题在AArch64或x86上难以复现，却能在m68k平台重现(反之亦然)。
虽不足以成为数十人持续维护的充分理由，但这绝非纯粹的学术娱乐或怀旧情结。
m68k架构已有LLVM移植版本，因此Rust可在此平台实现[0]。若能为alpha、hppa和sh4架构开发LLVM后端将更理想——这些老旧架构通常结构简单，可运行的LLVM后端既能作为参考范本，也极具教育价值。
(LLVM曾内置DEC Alpha后端，但该版本发布于2011年，与任何Rust版本均无关联。)
[0] 目前仅有基础初始支持，尚未实现'core'或'std'库的完整构建。https://doc.rust-lang.org/rustc/platform-support/m68k-unknow… 此问题应可修复。
理论上，codegen_gcc项目[1]是否应允许Rust支持仅由GCC提供的后端？
[1] https://github.com/rust-lang/rustc_codegen_gcc
https://lists.debian.org/debian-devel/2025/11/msg00010.html
LLVM因其他优势(如LLVMpipe)更具吸引力，因此投入有限资源开发LLVM端口，可能比改进和维护针对GCC的重定位rustc更具价值。
是与否
从纯代码生成角度看是
但所有条件编译的平台特定代码均缺失
因此使用 #[no_core] 应该可行(假设后端 WIP 部分不是问题)。但除此之外，你必须先移植 libcore(应该可行)，然后是 libstd(工作量相当大)。
是的，这正在进行中。
据我所知，m68k LLVM移植版与Linux上的GCC存在ABI兼容性问题，根源在于对齐错误：https://wiki.debian.org/M68k/Alignment (页面说明LLVM包因此无法构建)
解决此问题的根本方法是为m68k-unknown-linux-gnu目标三重组合定义新的ABI后缀，替换现有的'gnu'后缀——该后缀保留了GCC对int类型2字节对齐的兼容性。
这些对Ubuntu毫无商业价值。
虽然这话看似正确，但对Debian真有意义吗？:)
发帖者正受雇于Ubuntu。
确实如此，但Linux内核及主流发行版的多数核心贡献者都受雇于具有商业利益的公司，而这些公司通常不会投入资源维护旧架构。
当然也有部分人受雇于基金会——这些基金会虽由企业资助，但存在一定程度的决策独立性。
还有些人自掏腰包参与，例如完全自愿的工作，但多数开发者无法长期承担如此高时间投入的工作。因此许多重大变更和贡献最终都来自直接或间接受企业“资助”的人员。
这种现象在多数“历史悠久、规模庞大、可持续且仍在发展的开源项目”中相当普遍。
此处需添加疑问句式或佐证。
直接查阅邮件列表签名即可：
https://mastodon.social/@juliank
>Canonical公司高级工程师。
确实存在协同效应，但请记住我也有个人立场
[已删除]
在未提供反证的情况下，这种说法有失公允——而你并未提出任何证据。
事实上，Linux(及开源领域)中大量高频使用的组件必然存在 某种程度 的商业参与。难道我们主张所有使用Linux的企业都不应支付开发者报酬？这在我看来反而更糟。
无论你是否认同，Linux/开源领域早已不是 纯粹 由无偿爱好者主导的领域——这种状态早已不复存在。
https://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog
我不明白人们为何总对企业抱有善意假设。
它们不是人。它们毫无愧疚，更无羞耻之心。
不过朱利安·克洛德并非企业实体，所以我们应该给予他怀疑的余地。
整个讨论的起因是有人提出了错误观点：
>它们对Ubuntu毫无商业价值。
这显然是错误的。
朱利安可以信奉任何理念，事实上他越天真理想化，对Canonical越有利。
关键在于企业版Linux的盈利模式依赖于复杂到难以部署的系统环境。这正是其商业本质——部署越繁琐，收益越丰厚。Rust语言完美契合这种商业模式。
经历过红帽这类所谓自由软件捍卫者无数次地毯式抽走支持后，人们本该明白这个道理。
与其暗示，能否具体说明你认为这里存在何种不当行为？
https://news.ycombinator.com/newsguidelines.html
> 假定善意。
容我为你阐明：
你不仅要避免不当行为的表象，更要杜绝不当行为本身。
你是故意嘲讽有工作的人耍小聪明，还是认为这个技术决策本身有问题？
这太恶劣了。你只为雇主利益奔走吗？还指望别人默认如此？
Canonical在这方面本就不算恶名昭彰。
更关键的是这些架构都属于“非官方支持”范畴，而非“可能获得官方支持”的状态，因此长期以来对Debian整体而言都价值有限
这些架构似乎都已完全淘汰，所以它们要么继续使用最新支持它们的Debian版本，要么另建自己的发行版。(或者添加Rust支持？不过这恐怕不现实。)
> 那么这对这些架构意味着什么？
它们将被重新定位为“复古计算设备”
多数架构无需更名。Alpha和hppa本就是复古计算设备，且分别已停产18年和15年。Sh4今年已消亡。唯有m68k仍在坚持，但其用户数量已微不足道。
m68k计算机不就是1990年代和1980年代的几款机型，外加些近年业余爱好者项目吗？这完全属于复古计算爱好者范畴。
我虽不涉足Debian领域，但这类系统似乎更适合采用专属发行版，而非成为大众市场的负担。毕竟它们本就无法运行任何桌面环境的标准配置。
m68k架构至今仍应用于众多嵌入式系统。(我)不清楚其中有多少运行Linux(而非其他嵌入式操作系统)，但估计至少部分如此。同样不清楚有多少系统运行(或希望运行)Debian而非其他发行版(我首先想到的是定制版Yacto发行版)，但这个数字可能不为零。也可能有人使用非Debian发行版，却依赖Debian软件包获取更新。
Debian是否该在意？我无法断言。
搜索“嵌入式m68k Linux发行版”时，我发现人们要么在寻找替代方案，要么在开发替代方案——因为十五年前Debian就被认为“过于臃肿”。
我不理解“复古计算”这类说辞的喧嚣。我怀疑真有人出于必要在这些设备上运行Debian——就像用复原古乐器演奏巴洛克音乐的人，也不会介意被称为“早期音乐”爱好者。
嗯，我们正致力于打造通用操作系统。或许吧。
但我不确定。我认为新增的Rust依赖项很不错。理想情况下，关注小众系统的人们会挺身而出，协助Rust实现对这些系统的支持。
> 理想情况下，关注小众系统的人们会挺身而出，协助Rust实现对这些系统的支持。
实际上，我正是将m68k目标添加到Rust编译器的人，也是推动后端集成到LLVM的核心力量之一。
总体而言，为Rust编译器添加新后端并非易事——当前这取决于LLVM的支持，因此要求他人直接完成此事未免有些傲慢。
所幸rustc_codegen_gcc和gccrs两条开发线都在推进，未来必将解决此问题。
抱歉，我并非暗示此事微不足道或无人为此付出。本应更谨慎地表达观点。
我试着重新表述：如果我们永远不想放弃对过去支持过的平台的支持，那么我认为只有两种选择：(1) 永远不采用需要额外付出才能支持这些平台的新技术，或 (2) 将支持工作交给那些关注小众领域的人来确保。
两者皆非易事，但前者似乎注定走向停滞。
不过看到Rust的两条编译器路径都在推进真是令人欣喜！感谢！
关于SH-4的细节很有意思。我以为瑞萨此前承诺过零件供应将持续到2029年？
SH-4虽列入产品长寿计划https://www.renesas.com/en/support/product-longevity-program…，但具体含义我实在难以揣测。目前状态显示为“最后采购期”。
若有人对邮件措辞存疑，需提醒各位：此人正是Debian系统keepassxc软件包的维护者。
以下是该用户侮辱上游开发者及Debian软件包用户的讨论串：https://github.com/keepassxreboot/keepassxc/issues/10725
坦白说，无论是这封邮件还是你提供的讨论链接中，我都未读到侮辱性言论。如果我没看错，该讨论串里只有那个人发表过一条评论，对吧？该评论措辞直白，使用了可能被视为不专业的词汇(“垃圾”/‘烂透了’)，但并未侮辱用户(用户并未被称为“烂透了”)。邮件内容亦是如此。
照例又是无谓的闹剧…
我认为这种措辞并非不专业，而是直截了当地表达了个人观点。
提出要求的正是keepassxc的维护者，他本该直接关闭该问题——毕竟这是Debian特有的问题，用户只需按此方式安装即可。
浏览器集成是任何密码管理器都应具备的基础功能。缺少这项功能对大多数用户而言毫无用处。
事实上，缺乏集成反而会诱导用户使用复制粘贴，降低安全性。
下一步该怎么做？为了减少攻击面而剥夺浏览器的JavaScript支持？
我实在不明白这有什么好讨论的。要么他是被Canonical雇佣的破坏者，要么就是彻底疯了。
人们主要不满的是行动意图表述清晰、精准且简洁，而非含糊其辞。这是对讨论的诉求。
这与是否开放讨论是两回事——若有人能提出合理论据(而非“你破坏了不支持且小众的功能”这类说辞)，而有人声称他不愿接受辩论
坦白说，若有人因变更增加了深度安全防护(2)而将用户置于实际相关安全风险(1)中，却又暗指用户“想要垃圾方案”，这在我看来极具警示意义。
(1): 复制粘贴密码极其危险，问题在于“相似域名”钓鱼攻击。密码管理器不会自动填充此类域名，而手动复制粘贴极易中招。此外还涉及剪贴板安全等次要问题(故KC会在短时间后清空剪贴板)。
(2): 移除可能存在漏洞的冗余功能。但我们讨论的是来自同一源代码的功能模块，若未启用/配置则基本不会产生影响(尽管仍可能引入某些依赖项)。
但确实是场毫无必要的闹剧
我认为HN帖子本身并不具对抗性，但某些人却如此解读，真奇怪。
传统C项目对任何Rust相关内容的条件反射式抵触已近乎病态。那封邮件在保持礼貌的同时，完全没有姑息纵容之意。
请务必记住，参与这类事务的许多人存在某种神经多样性，可能难以应对变化。
正如teh64在https://news.ycombinator.com/item?id=45784445 数小时前所言，约四年前我的立场曾发生180度转变，若当时看到如今的提案，恐怕也会产生同样的抵触情绪。
所有这些变更都需要投入工作。因此其他优先事项将获得较少关注。若因转向Rust的繁重工作导致严重安全漏洞被遗漏或引入，那将极具讽刺意味。新编写的Rust代码很可能远不如现有源代码成熟。最终结果很可能(实际上极大概率)是耗费大量精力却反而削弱了安全性。
关于这类类型安全语言的学术研究大多得出空结果(若你持异议，说明你未曾研读相关文献)。这恰恰证明其行不通，你本就不该采用这些技术。安全是持续改进的过程，而非灵丹妙药，而“直接转用Rust”恰恰是种极具诱惑力的伪解药。
倒不是说我急着转向Rust并全力投入，这根本排在最低优先级事项里。
许多Rust重写项目存在致命缺陷：它们要求采用与原代码不同的许可证，因此无法查看代码只能从零重写。
但我们的思路是：嘿，这段关键代码可能藏着漏洞(其中反复出现的段错误真是令人头疼)，我们只需将.cc代码复制到.rs文件，尽可能少地修改它就能让它编译通过。
真正的难题在于配置解析器这类模块——它确实亟需彻底重写，因为现有代码过于粗糙，严重阻碍了集成工作。
理想状态下，我会在C++代码中添加注释，最后由工具完成向Rust的转换；就像当年Go编译器从C语言转译为Go语言那样。那真是辉煌的时刻。
注：180，供其他困惑者参考。
/me 羞愧地躲起来
你说得对，这家伙真是个混蛋。看到邮件内容时我立刻查了发件人，想起那个“守门人”帖子就忍不住笑出声。
多么可悲的思维方式。我永远无法理解这种“安全”论调。
移除功能并非最安全的选择。既然如此干脆把所有功能都撤掉。只有当电脑完全无法运行时，才能实现100%的安全。
> 移除功能并非最安全的选择。
若我拥有一个仅加密解密密码的程序，其攻击面远小于同时具备浏览器集成等众多功能的程序。每个功能都可能让这份清单更长：https://keepass.info/help/kb/sec_issues.html，这适用于任何软件。
同时，人们也可以辩称：安全但毫无实用功能的软件同样毫无价值。基于上述讨论，提供精简版与完整版的方案极具合理性——我选择精简版因无需额外功能，而他人或许能从完整版获益良多。
与浏览器集成的密码管理程序能大幅减少攻击面。若无法直接访问剪贴板，意味着系统中其他程序也能读取密码。
有些人根本不理解安全性的真正含义。
安全性的存在是为了确保功能在无中断、无风险的状态下正常使用。
例如：当服务需要保持可访问性时，将计算机断开网络连接并非安全措施。
这种说法有误。当某个软件包的核心功能是X，却包含晦涩功能Y时，即使用户从未使用过Y，其存在本身就可能引发安全问题——这才是正当讨论的焦点。
具体案例：Log4j漏洞本质上就是允许任意代码执行的功能直接导致的后果。几乎没有Log4j用户会主动使用该功能，但所有用户都因Log4j存在该功能而面临风险。
修复该CVE的有效方案就是移除该功能。若有人能预见性地将Log4j精简为仅包含~普遍使用功能的版本，并为有意使用该功能的边缘用户单独发布Log4j-maximal版本，本可避免这场堪称史上最严重的安全漏洞。
就本讨论主题而言，似乎无人否认应存在“精简版”与“完整版”之分，且精简版必然更安全。整场争论的焦点在于：究竟该沿用现有包名作为精简版还是完整版？
这本质上是在权衡两种方案：“让现有不使用附加功能的用户默认获得最高安全保障”，还是“确保现有使用附加功能的用户升级后不出现故障”。
> 这说法有问题；核心用例为X的软件包若包含晦涩功能Y，即便用户从未打算使用Y，其存在本身就可能引发安全隐患——这才是真正值得讨论的议题。
在此情况下，该功能是否属于冷门特性完全无法确定。对多数用户而言，它可能恰恰是必不可少的，甚至是整个软件的核心需求。
但许多用户正依赖这些功能，因此才提交了错误报告。
这简直如同帮亲戚关掉电脑来提升安全性——问题解决了？
若因默认设置存在安全漏洞而犯错，本可通过添加提示信息来引导不使用附加功能的用户采用精简版本。但仅以“安全”为名突然撤换所有功能，还对受影响用户出言不逊？我实在无法理解这种行为逻辑。
这叫openBSD嘛 :)(别误会，openBSD很棒，但默认安装的开箱即保安全模式确实有点简陋哈哈)
最让我恼火的是，他仅因个人不常用某些功能就称其为“垃圾”，还用毫无依据的臆断收尾，声称该版本“增加了路过攻击的风险”。开发者明明解释过这些功能并非插件，甚至默认未启用。Debian内部维护者这种傲慢态度，比任何外部势力都更会损害项目声誉。
说得对，正是这种粗鲁冒犯的行为让许多人对开源望而却步。并非所有人都愿意耗费时间精力参与软件架构的意识形态之争。
我们更应重视保障现有用户配置的稳定性。功能破坏造成的损害极其严重，其影响可能远超不安全的默认设置。
> 他把功能称作“垃圾”，仅仅是因为自己可能不使用这些功能
“这些功能纯属多余，根本不该出现在本地密码数据库管理器里”——这番论述已相当明确地解释了这些功能为何是“垃圾”，显然与个人喜好无关。
有些人重视模块化。
你误解了，看：这些人根本是企业破坏者。
可悲的是，这种文化已在自由软件界蔓延——开发者欢欣鼓舞地牺牲真实用户利益，只为讨好某个虚构的、他们 希望 迎合的理想化用户。始作俑者或许是GNOME 3(刻意削减功能、主动抵制定制化、浪费屏幕空间，只为追逐人机交互学预言的移动触控设备转型——而这种转型在桌面Linux领域从未实现)，但Mozilla却以安全之名将其发扬光大。
不知是缺乏安全感还是不够成熟，每当这类争议出现，我总在想：Rust爱好者为何不直接用自己的“现代”而非“复古”技术来证明观点？若真能打造更优方案，何不付诸实践？当人们看到实际效益时自然会转向。这种“必须在既有项目中接纳Rust”的寄生模式实在令人反感，其引发的抱怨就是明证。我欣赏Redox这类坚持自我路线的项目…为何Rust社区不团结起来支持这类项目，将其打造成人们争相使用的无漏洞杰作？
这封邮件来自Debian维护者，讨论Debian引入Rust的新硬性依赖关系。绝非某个Rust狂热分子强迫Debian团队违背意愿采用Rust。
诚然存在某些令人反感的“你该用Rust重写这个”的家伙，但此案例绝非如此。
Debian维护者总数约1000人吧？此人不能代表整个项目。据我所见，他确实是在告知Debian成员：无论你们是否愿意，无论你们偏好的架构是否受支持，都必须接受Rust。或许存在组织层面的投票，但讨论中并未提及。原文说的是“我计划”，而非“Debian决定”。
无论如何，我的观点是更合理的做法应该是声明：“我将引入一个基于Rust的apt分支版本，并提供将其设为系统默认apt的方法(供偏好者选择)”，然后在接下来一年左右的时间里，他可以宣称“看看这些卓越的优势！”(如果真有的话)。届时社区自然能根据实际表现——无论是性能、安全性、“现代化”程度或其他维度——决定是否将Rust版本设为默认。
你似乎将“Rust爱好者”视为某个组织严密的群体，认为他们纯粹为了编写Rust而存在。但Rust早已远离这种极端早期采用者的阶段。
你现在看到的是开发者们希望改进他们正在开发的项目，并选择用Rust实现这一目标。这并非一群“Rust狂热分子”潜入项目组搞破坏，而是越来越多的开发者将Rust作为完成工作的工具，而非参与语言之争。
不，我提到的redox和另一位评论者举例的ripgrep，恰恰是我更希望看到的范例——这些项目同样出自所谓Rust爱好者之手。我并不认为他们构成单一的群体。
我们分歧在于：我不会把将Rust注入现有项目称为“编写更优版本”。如果他们真能编写出更优版本，我当然乐见其成——这样我们就能在切换前见证其优势。
> 我的观点是，更合理的做法应该是声明“我将推出一个氧化版的apt分支，并提供将其设为系统默认apt的方案”，然后在接下来一年左右的时间里展示“这些卓越的优势！”(如果确实存在的话)。届时社区才能基于“更优/更安全/更现代化”等理由决定是否将Rust版本设为默认。
开源软件开发并非如此运作。
林纳斯从未征询我意见：ipchains是否该取代ipfirewall成为默认方案，iptables是否该取代ipchains。
没人问过我GCC是否该用C++替代C语言来编译自身。
类似例子不胜枚举。
为何APT要例外？为何要求维护者必须分叉项目才能引入变更？为何要由一个未定义的“社区”(究竟是谁？显然不是APT开发者…)来决定？难道APT每次代码变更都得如此操作？
ripgrep的遭遇正是如此。人们似乎很欣赏它。
完全正确！人们钟爱ripgrep正是因其显著优势，若开发者曾考虑为其添加posix模式，我确信至少部分发行版早已将其设为默认选项。
uutils就是这么做的。我每天都在用它们。
我确实喜欢用Rust编程。但随着其他语言逐渐迎头赶上，我的立场这些年有所转变。更何况我对重写古老工具能否提升安全性持强烈怀疑态度。我不了解apt的源代码，也不清楚它在命令行界面背后的实际运作机制，因此将判断权交给专业人士。但当前似乎存在一股强劲的潮流，试图用Rust重写所有核心系统。我对此的质疑在于：这些工具既未创造任何新事物，也未改变/改善现状。我理解在不破坏现有系统的前提下引入新系统确实困难。但我们的系统仍根植于电报时代的决策逻辑，层层叠加的架构已然固化。
关于重写议题，我注意到两个常被忽略的论点。虽然两者都存在合理反驳，但我认为它们为讨论增添了重要维度，或许能解释为何缺乏这些视角时重写显得缺乏正当性。
* 如今越来越难找到愿意接触C或C++等古老语言代码库的新开发者。部分开源项目坦言重构为Rust语言，正是为了吸引新开发者加入。
* 可靠性可通过多年使用验证，但安全性与使用时长关联性较弱。可靠性是围绕预期使用场景的“理想路径”展开的统计分布，软件使用次数越多，其健壮性就越强或越易被验证。但安全问题本质上属于最边缘的极端案例，无法通过常规使用发现，只能通过直接攻击和渗透测试揭露。断言旧软件经受过所有可能攻击方式的考验，远比断言其经历过所有可能使用场景更困难。CVE漏洞的后果往往远比边缘案例可靠性缺陷严重，这使得主动强化安全性的必要性更为凸显。
我理解吸引新生力量的考量。但重写的核心工具是否由原始维护者完成？更关键的是，为何不直接采用现代架构等全新方案，而非简单替换？
关于第二点：航空航天与汽车工业是如何处理的？它们高度依赖经过验证的概念。当引入新型材料替代旧材料时，或当整个装配流程更新时，它们采取什么措施？
> 再次提出疑问：为何不直接开发全新方案？
世界并非非黑即白。有些人编写Rust程序时，意图使其成为其他程序的即插即用兼容版本。(顺便说一句，那个“其他程序”本身可能就是更古老程序的重写版本。)
而另一些人，比如我，编写的Rust程序可能与旧程序 相似(也可能完全不同)，但绝非即插即用的替代品。例如ripgrep、xsv、fd、bat、hyperfine等项目。
我不明白你为何执着于将Rust程序限定为即插即用的重写版本。请接纳现实世界中灰色地带的复杂性与微妙差异。
> 再次重申：为何不直接编写全新代码？
Rust正涌现大量全新作品。但当有人宣布用Rust编写新基础设施时，HN上不会出现这类讨论，只有在完全或部分重写时才会引发热议。
关于汽车及其他传统行业，安全与防护都存在严苛流程。需要执行危害分析与风险评估(HARAs/TARAs)，为特定组件和功能分配威胁或安全等级，进行深度系统分析，添加安全冗余措施，遵循MISRA等编码标准。基于久经考验的代码，你无法获得太多“免费”的安全保障。但在国防领域，已大力推动采用内存安全语言以缩小攻击面。
> 为何不直接编写新代码？
因为需要向后兼容性。你不会为修正旧错误而从头重写Linux——那等于创建全新系统。虽然确实有人在这么做。但用面向未来的语言重写现有系统仍有价值，这样在新系统就绪前，我们就能拥有更完善且可用的系统。
抱歉。我必须回应这个观点，因为大家似乎对“新”这个概念有些纠结。可能是语言障碍。我完全理解向后兼容等原因。我想强调的是：我们耗费大量时间维护五十年前编写的软件，或是以相同理念重写现有系统。我将评论与安全层面混为一谈，导致关于“新”的论点显得混乱。这种现象在HN上也很常见。我推崇UNIX哲学和POSIX理念，但它们被奉若操作系统设计的圣杯，尤其POSIX被视作唯一的跨平台标准。再看看CPU启动时必须经历的步骤：先假装自己是40年前的变体，再逐个启动功能模块。希望我的观点已阐明清楚 🙂
编写符合POSIX标准的工具，并不意味着将其奉为“操作系统设计的圣杯”。我确实用POSIX指导过自己构建产品的某些设计维度——并非认为它至高无上。事实上我认为它糟糕透顶，尤其厌恶某些人将其当作榔头来抱怨可移植性。但POSIX确实无处不在。若想降低用户使用门槛，实难忽视其存在。
顺带一提，“重写旧软件”的理念并非Rust首创。早在Rust程序员之前，GNU就已践行多年。
邀请缺乏经验的业余者参与重大项目，绝非明智之举。不，这根本是灾难的配方。
> 或改变/改善现状 [quo]
uutils/coreutils采用MIT许可证，主要托管于GitHub(问题与PR均在此处理)，而GNU coreutils采用GPL许可证，托管于gnu.org(通过邮件列表管理)。
编辑：此非个人观点，仅陈述事实。许可证变更确实可能引起某些公司的兴趣。
这无疑是退步之举。
GPL保护用户自由，而MIT许可的软件极易遭科技巨头抽走地毯或被其收编。
使用GitHub不可接受，因其封禁多国用户，这将阻碍全球开发者贡献力量。况且它归微软所有。
我们用一个依赖微软和美国政府意愿的中心化仓库，取代了强大的copyleft许可和稳固的去中心化工作流程，这竟被视为好事？
> GPL保护用户自由，而MIT许可的软件极易被科技巨头抽走地毯或收编。
这完全不成立。若有人将项目许可从MIT改为专有许可，原始版本仍将存在且用户可继续获取。自由并未丧失。
采用GPL时，我能编译自己的副本并与 他们的 软件配合使用。他们 必须允许这种行为，还必须提供包含修改内容的源代码。
MIT许可证简直是开源社区的闹剧。
说来遗憾，尽管我厌恶这些封禁措施，但从大局来看这种排斥实在微不足道，GitHub带来的益处足以让大多数人接受这种权衡。我正是其中一员——年仅25岁的我通过GitHub接触Git，早已习惯这个平台。不过我也正在开发Codeforge作为业余项目，或许未来会发展成正式事业。
还有另一类人完全附和美国外交政策，对那些国家的公民怀有同样的敌意(我见过大量此类例子)。
至于许可证问题，我实在不理解“核心工具重写版会遭遇跑路”的论点——这并非托管服务，不会出现Minio[1][2]那样的状况，即便真有意外，原始工具始终可用。
[1] http://news.ycombinator.com/item?id=45665452 [2] https://news.ycombinator.com/item?id=44136108
包括我在内的2位GNU核心工具维护者，通过我们维护的GitHub镜像[1]监控问题与PR。不过通常更推荐使用邮件列表，因为关注者更多。
[1] https://github.com/coreutils/coreutils
人们总要从某个项目开始学习。为什么不选择一个易于测试的项目呢？你清楚它 应该 实现的功能，那就重写吧！
重写版本是否应取代原版固然值得深入讨论。但单纯编写替代方案本身不值得抱怨。
我认为多语言支持带来的问题远多于解决的问题。如今构建发行版需要多少种不同的工具链和包管理器，简直令人作呕。有人要Python，有人要Node，有人要Go，现在又来这个。用Node我们用供应链攻击换来了缓冲区溢出。如果他们不要C语言，不如从头开始。Robert Morris用Go重写了足够多的Linux使其可用，性能开销仅比C慢5-15%。若目标是全面采用Rust，请贡献给Redox项目，他们在该道路上已走得更远。
每个项目都应设定边界。Debian作为大型项目，理应比小型项目提供更多选项。Rust已足够普及，Debian将其列为官方支持选项完全合理。
需注意：我并非主张Debian必须这么做，而是认为其采取此举合乎情理。我并非Debian维护者，因此无权对他们使用的工具发表意见，仅认为添加Rust并非不合理。为引入Rust而移除其他工具或许合理——同样，这不该由我评判，而应由Debian维护者决定。
遗憾的是，世界本就复杂。每种语言都有其独特优势与权衡取舍，各自适用于特定场景(试问机器学习科学家能否转用原始C语言？)，因此所有语言(除JavaScript外)在软件殿堂中都占据着合理位置。作为务实的操作系统，Debian需要适应现实需求——解决普遍可用性问题，因而必须支持所有这些语言。若试图用单一语言重写所有组件，不仅耗时巨大且成效甚微；而支持像Redox这样声誉较低、基础不稳的操作系统，其破坏性甚至可能超过从头重写Debian(宣称目标是“用Rust重写一切”略显夸张)。因此，逐步替换关键组件(如apt解析器等)才是更现实的方案。虽然操作系统绝不应“快速迭代、频繁破坏”(尤其像Debian这样的系统)，但我认为放弃支持那些无法运行近十年前发布的语言的架构，并非荒谬之举。采用经实践验证的语言(Rust如今已算成熟，对吧？)——它比C语言更不易因修改而自毁， 同时兼具直接编译特性，还能在标准应用中与常规C库良好交互——在我看来这简直是超值的交易。
Linux早在二十年前就放弃了对抗复杂性的斗争。
难道不该等待(或支持)其中一个 Rust-for-GCC 移植版本成熟可用吗？据我所知，在 GCC 支持之前，内核中使用 Rust 也不会成为强制要求。更何况，多个实现版本的存在能确保语言发展不会再像以前那样快速迭代导致兼容性问题。GCC上游已存在Rust支持，因此我认为距离可用状态并不遥远——至少对明确选择Rust的项目而言。
此外，若现在就将这些架构从Debian更新中移除，当未来出现支持它们的Rust工具链时，重新纳入现代Debian是否会陷入官僚主义的噩梦？
> 此外，若现在就将这些架构从Debian更新中移除，当未来出现支持它们的Rust工具链时，将其重新纳入现代Debian是否会陷入官僚主义噩梦？
这些架构并非现在才从Debian主分支移除，它们早在十多年前就被移除了。这不会改变它们的现状，也不会影响它们重返Debian主分支的可能性——这种可能性实际上早已不复存在。
所有列出的架构都已不再获得Debian官方支持
换言之，它们仅因未引发重大问题且有人闲暇时自发修复才得以存续
因此，除非有企业承担(工作时间成本)——此处指长期维护而非初始引入成本——否则这些架构一旦移除便极难回归
但基于相同原因，当未来可能因变更而淘汰它们时(只要没有企业挺身承担维护所需的工作时间成本)，这些架构几乎毫无相关性可言
移植版本不属于Debian核心，尤其不会随Debian正式版发布，仅在不稳定版中提供。
已稍作措辞调整，感谢指正
GCC已具备上游Rust支持，因此我认为其可用性并不遥远——至少对明确选择Rust作为目标语言的项目而言。
当前GCCRS项目连libcore都无法构建，更遑论libstd。此外，该项目当前仅支持Rust 1.50的功能集，并添加了Linux内核所需的特性。我认为它短期内难以成为实用的通用编译器。
更可能的情况是rustc_codegen_gcc(据我所知它目前 能够 构建libcore和libstd)会率先实现稳定。
这位维护者正是当年破坏Debian版KeePass后在讨论串对所有人竖中指的家伙。真该有人拉他到一边好好说清楚：世界不会围绕他转，更不会为他编造问题来证明自己薪水的合理性。
https://github.com/keepassxreboot/keepassxc/issues/10725#iss…
有趣的是人的观点竟能如此转变：https://news.ycombinator.com/item?id=27594688
但愿更多人能像这样随时间推移改变观点，而非固执己见。
但愿能给出理由。原文如下：
> Rust是安全噩梦。为Sequoia项目需向主分支添加130多个包，且每次安全更新都得重编译所有依赖。
情况有何变化？为何加密应用的130个包突然变得合理了？
大概是因为过去四年间新增了120个(*)依赖包。
(*) 随机数
这取决于最初的观点是经过理性论证还是仅基于个人感受。
依赖项激增仍是问题，且我尚未见到切实解决方案。若能了解他们转变观点的原因会很有意思……我猜想或许是预期的收益压倒了所有顾虑，加上迄今尚未出现重大供应链攻击事件。
我认为APT采用Rust是管理层决策，类似于核心工具包转向Rust版本的决定。
请相信这是我个人的决定。最后一段是我对某位Debian开发者兼CTTE成员观点的转述。
与其合作那些看似温顺却思想僵化的人，我更愿与他人眼中尖锐但沟通方式与我相似、且思想开明的人共事。
我乐见所有开发者使用自己偏爱的编程语言。三十余载编程生涯中，我目睹过整个技术生态的兴衰更替。
我实在不明白Rust开发者为何有如此强烈的需求去贬低他人。这和systemd团队以及LP散发出的气息如出一辙。难道他们内心深处存在心理问题，潜意识里知道自己需要通过贬低他人来获得心理补偿？
记得当年C语言和Pascal语言的争论，但那根本不算什么。如今的C/C++开发者完全不需要向任何人证明什么。若C开发者四处贬低Rust开发者反倒显得奇怪，但反向情况却屡见不鲜。
究竟是谁在何处贬低他人？
根据此帖及众多类似讨论，贬低Rust用户的正是反Rust狂热分子。
根本问题在于当今网络充斥着太多活动分子。我曾自称活动分子，但如今这个词已沦为污名——我将其与偏执行为、骚扰、封杀企图以及为达成目的而肆意妄为的恶劣行径联系在一起。
我认为这源于宗教影响力衰退与社交媒体令人发狂的双重作用。许多事业都在招揽“真信徒”，逐渐演变成宗教，而社交媒体正是他们传教的工具。
Rust虽属温和案例，却依然吸引着传教士。
因此，人变了，西方社会变了，社交媒体赋予人人发声权的同时，也激发了人性最阴暗的一面。
> 我不明白Rust开发者为何有种强烈的侮辱他人欲望
…在哪儿？
Rust开发者有企业支持，因此自视甚高——尽管这语言不过是丑陋的OCaml山寨版。
他们有底气做正确的事，因为他们的语言内存安全，这永远意味着绝对安全。反讽结束。
依我之见，Rust证明了许多程序员宁可选择过度设计、冗余复杂且晦涩难懂的语法，也不愿采用严谨的语言设计。我个人认为他们潜意识里喜欢让自己的技艺保持玄奥和“魔法感”。如今可读性、简洁性及KISS原则的重要性根本没被充分强调。
这项指令出自Canonical员工之口令我不安。毕竟若转换方案仅凭自身价值合理，本应自然发生，无需如此对抗性的沟通。
Canonical的长期布局究竟是什么？
Apt仅列出3位维护者，而根据Git历史记录，此人承担了90%的工作量。由他来决定，恰恰说明这并非自然而然发生。
开源本质上是行动主义(所有开源许可证都明确规定)。行动者即决策者；而如今越来越常见的是，支撑数百万用户使用的工具，往往仅由一两人维护。
很难想象选择用其他语言编写包管理器存在恶意的经济动机。..
显而易见的动机可能是打造更可靠的产品，或通过提供现代工具提升员工效率…或许还能设想某种合规/法律/监管战的准备——此时转向内存安全工具确实重要，但即便如此，我更倾向认为微软在这方面更有话语权，而Canonical的任何举措都属于防御性行为。
“Canonical的长期战略是什么？”
推测是将APT中关键的解析代码重写为内存安全的语言。
长远目标是驱逐社区参与者，在APT/Debian生态系统中建立企业控制权。
这是否意味着Debian作为GNU/Linux的终结？Rust核心工具链并非GNU项目，gccrs仍未完成，且现有GNU库与工具的Rust重写版本大多采用MIT等非GPL许可证。
主要Python和Perl工具链也从未由GNU维护。Python从未采用GPL许可证分发。Perl的许可历史我不完全确定，但它似乎始终提供非GPL版本(同时也有GPL版本——至少近期如此，不确定是否一直如此)。
这似乎不足以改变 GNU/Linux 命名准确性的程度…不过在描述 Debian 时，我认为有许多比 GNU 更重要的因素(例如 systemd)。
编辑：查证发现Perl 1.0采用过以下非商业许可协议，因此确实并非始终遵循GPL。不过若您真在意的话，现在的问题是Debian采用该语言时的许可状态了。
> 只要您不试图从中牟利或冒充作者，即可复制Perl工具包的全部或部分内容。
https://github.com/AnaTofuZ/Perl-1.0/blob/master/README.orig
GNU/Linux这个名称本质上是GNU项目在抢功劳。他们从未完全负责用户空间的开发。
不过现在确实有更多替代方案，在非copyleft许可证下取代了GNU的贡献。
实在难以视作其他含义。
看来又到了每月例行的Rust剧场时间。
严肃地说，我认为Linux整体上若能适度清理遗留代码并拥抱新事物会更有利，因此我将此视为积极进展。
Rust令人头疼的一大问题在于，它相较于C语言普遍支持的指令集架构(ISA)目标缺乏多样性。我明白部分原因在于C语言编写基础编译器相对简单(相较于C++这类复杂语言)，且历史悠久，但为何不推动Rust编译器至少支持Debian所有ISA架构？
多数人也不会为C语言编写基础编译器，无论是否“相对简单”。人们更倾向于为现有编译器添加新目标，这显然容易得多。
为Rust添加新后端同样“相对容易”。
Rust的政策文档在此：https://doc.rust-lang.org/rustc/target-tier-policy.html
可能出错的情况很多。你需要能够测试。而测试的前提是有人拥有测试硬件。
这种语言本质是严厉的爱，尽管首位回应者持反对意见，我仍认为其重要性不容忽视。
大量措辞似乎源于内核世界中围绕Rust使用的令人作呕的互动经历。
我对Rust的抵触源于内核讨论中未提及的原因，但我也并非反对推进。我不太理解为何要抵制内存安全语言，以及对采用现代工具/语言的过度防备心态。
我认为问题在于将Rust视为必然选择的论调。个人认为Rust存在严重缺陷，所谓“现代”更多是个人偏好。历史上推动C++、Java等托管语言的浪潮亦是如此。不同之处在于，如今自由软件运动已被企业利益过度操控，导致某些变革强行推进，损害了社区其他群体的利益。过去若想推动变革却未达成共识，人们会创建分叉项目，若其确实更优，最终会被主流接纳。如今，主导开发资金的企业正强力推行自身利益，持异议的社群成员被迫出局。这种行为被冠以“不愿适应”等宣传话术合理化。自由软件的精髓本应在于：若我拒绝接受某些企业定义的“现代”标准，就不必被迫妥协。这正是我远离微软的原因。
> 我认为问题在于将Rust必然视为未来方向的宣传策略。
我并未在Rust身上看到这种倾向。显然许多人认为Rust是适合我们的未来方向，但你所指的问题在于：没有出现你更青睐的替代方案，这与Rust无关。
若鲍勃为所有想吃披萨的人订购披萨，这并不意味着“披萨必然是未来方向”，你无法吃到迷你汉堡也非鲍勃之过——我想若你想要迷你汉堡，就该自己下单。当人们饥肠辘辘却无人订餐时，“披萨是未来方向”不过是默认选项罢了。
戴夫·亚伯拉罕的Hylo就像在这个比喻里有人主动提议订寿司。虽然戴夫是否知道本地有送寿司的店、寿司价格如何尚不明确，但这就是另一种前进方向的可能形态。
C++有配置文件机制，姑且称之为“规划概念”的解决方案；至于C…虽然这不是你的关注点，但没人研究这个吧？或许Fil-C才是你的未来？不过Fil-C同样无法支持这些过时目标平台。
[已删除]
争议点在于区分“存在某个群体[Rust社区]在强推/胁迫项目采用Rust”与“项目维护者主动选择使用Rust”。这两者常被混为一谈——尤其在这个论坛里，那些对Rust怀有偏见的人尤其如此。
你遗漏的关键字是：必然性。
所谓“过去不同”的说法不过是戴着玫瑰色眼镜的怀旧。项目维护者始终有权做出社区未必认同的选择——无论是否受企业支持的贡献者参与——而分叉项目以证明另一种立场更优的可能性至今依然存在。
没有人被迫离开社区，如果你愿意，可以分叉项目而不采用这些变更。这才是自由软件的真正意义——你拥有做出选择的自由。自由软件的核心理念从来不是让软件发展方向摆脱企业控制，项目维护者始终拥有自主决策权，无论是个体、企业还是混合模式。
软件自由的核心确在于我能创建自己的分支。个人项目维护者当然可以随心所欲。但当社区项目如Debian在未达成充分共识时，强行推进对部分社区成员造成代价的决策，这仍令人忧虑。这绝非首例。systemd的推行过程就存在类似问题(部分核心利益相关者的商业诉求)，我认为Debian确实因处理不当而遭受重创。社区活力与健康程度再未恢复至此前的水平。若此类情况持续，实属可悲。
> 未经充分共识强行推进
要求决策必须达成完全共识，无异于让决策陷入停滞。
> 未经充分共识强行推进
你如此描述，但现实世界通常并非如此运作。多数决才是行动准则。
不，这并非正常运作社区的行事方式。真正的社区基于社会契约行事，同时保护少数群体的权益。
我实在无法想象要耗费整个周六来剖析你在此处玩弄的言辞技巧。
…但像Debian这样的社区项目中，当某些决策会给部分群体带来代价却在未达成完全共识的情况下强行推进时，这依然令人担忧。
你能举出哪些具体案例证明决策曾获得 完全共识？是字面意义上的全民一致？所有用户都同意？
我怀疑很少有项目真正这样运作过。我们都听说过“终身仁慈独裁者”(BDfL)的概念。林纳斯偶尔也会做出行政决策。
> systemd的采用过程如出一辙(同样源于核心利益相关方的商业诉求)
虚假指控并不能让关于Rust缺陷的论调更具说服力。
> 若有人主张变革却未获认同，便创建分支；若方案确实更优，终将被主流接纳。
这假设了原本就存在分歧。
那么所谓“最终被多数人采纳”究竟指什么？当前的公告难道不正是这种采纳吗？
> 自由软件的核心价值在于：若我拒绝接受某些企业定义的“现代化”标准，就不必被迫妥协。
这点从未改变。
> 我认为问题在于将Rust必然视为未来方向的宣传策略。
那么替代方案是什么？内存安全问题确实存在，这点毫无疑问。
C/C++已成死胡同：技术社区彻底否决了Circle编译器这类技术方案，而“性能剖析”不过是海市蜃楼。他们 又一次 试图打造神奇编译器——既能自动拒绝所有劣质代码，又能接受所有优质代码，且 无需 任何代码修改，这显然不可能实现。
垃圾回收机制对仍在使用C/C++的开发者而言是致命缺陷，这直接淘汰了绝大多数内存安全语言。剩下的基本只有Zig和Rust。两者各有优劣，但Rust似乎更成熟且获得更广泛的社区支持。
在我看来，支持内存安全的人群在说：“我们的船上有个大洞，用Rust来修补吧”；而反对Rust的人群则高喊：“我不喜欢它的颜色，在有人发明完美解决方案前不该修补漏洞”。与此同时，船只正在下沉。我们是任凭少数喧嚣的Rust反对者沉船，还是让他们闭嘴或拿出更好的替代方案？
> 与此同时，船只正在下沉。
并非如此。我们拥有大量用C和C++编写的卓越而坚如磐石的软件。这些东西大多运行良好。
当然，总有改进空间，但没有理由现在就行动。这是需要长远考虑的决策，不必仓促行事。
> 剩下的选择基本只有Zig和Rust。
早在Rust出现前我们就拥有Ada，这可是相当出色的语言。事实证明安全对许多人并非首要考量，而C++显然足以胜任多数项目。
此外还有D语言、Nim语言、Odin语言等。
> 垃圾回收机制是重大阻碍
并非如此。80年代的Lisp机器就具备自动垃圾回收功能，而如今这项技术已大幅改进。因此我也不会完全排除这些语言。
简而言之，这艘船并未下沉。改善现状的途径众多。问题在于一旦依赖Rust，便难以抽身，因此与其仓促采用，不如深思熟虑。
基本正确，但Zig并非内存安全的语言。它在语法上或许优于C语言，标准库在编写不安全代码时的支持确实可能优于Rust，但从安全性角度看毫无吸引力。我相信即便是最狂热的Zig拥护者也会承认这一点。
> 对仍在使用C/C++的人而言，垃圾回收是个巨大的障碍。
问题不在于垃圾回收本身，而在于将 无处不在的 垃圾回收作为程序中唯一的内存管理策略。追踪式垃圾回收对某些程序或程序部分而言，确实是有效的内存管理策略。
> 从安全角度看它毫无吸引力
内存安全之所以重要(基于实践而非理论)，正是因为它是安全漏洞的常见根源。但空间内存安全比时间内存安全更关键，而Zig恰恰提供了空间内存安全保障。既然Rust的内存安全值得关注，Zig提供的内存安全同样值得重视。
作为极端软件正确性倡导者，我认为人们应当认识到：正确性、安全性(及其背后的原理)远比“语言是否严禁某些行为”这类二元问题复杂得多(否则ATS支持者会从其立场断言Rust与C同样不安全，因而毫无价值)。
这种复杂性远不止于空间安全与时间安全之争。例如代码审查已被证实是最有效的正确性保障措施之一，因此若某种语言能简化代码审查流程，从正确性/安全性角度看将极具价值。
我非常赞同你的观点，但关于空间安全在漏洞中占比更大的说法是否有依据？每当我想发表类似观点时，总预感到会有人贴出微软/谷歌宣称70%漏洞源于内存安全的文章链接。这两项“研究”(实为代码调查)似乎都将“释放后使用”归为主要漏洞类型。
Mitre将空间内存安全问题列在更靠前的位置：https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html(其危害性也超过KEV漏洞3倍以上)
Zig仅在Debug和ReleaseSafe构造中默认执行边界检查。若采用ReleaseFast或ReleaseSmall构造，它会无视边界限制进行读取：https://godbolt.org/z/733PxPEPY
这取决于策略设置。你也可以针对特定函数启用或禁用该功能。关键在于该语言与Rust同样提供可靠的空间安全保障(且两者都允许在特定代码段中启用或禁用该功能)。
不过默认设置和生态系统策略至关重要。
整个Rust生态系统都强烈倾向于优先保障内存安全和“构造即安全”。
这体现在标准库设计、crates的API设计思路、编译默认参数等方面…
在使用Rust的六年多时间里，我唯一遇到段错误的情况是在处理C代码的低级封装层或JIT编译时。
Zig拥有一些非常有趣的特性，但其语言和API设计方式留下了大量易出错的操作空间。
从技术上讲，一旦使用“unsafe”关键字，Rust就不再是内存安全的语言。Rust拥护者常在与其他底层语言对比时，试图兼得鱼与熊掌。但仅因在危险代码旁标注unsafe，并不能消除风险。
我曾编写大量底层/裸机Rust代码——unsafe无处不在且极不友好。此类场景下Rust的安全性保障大幅削弱，这正是Zig令我着迷的原因。
没有越界访问、没有怪异的类型强制转换、没有空指针——这些解决了我在C语言中遭遇的大部分问题。我只需证明代码不存在未分配缓冲区(或在非关键程序中无需证明)，就能以更低的复杂度达到与Rust相当的安全性。
unsafe机制的精髓在于：通过严格验证或借助Miri等工具确保局部不安全代码的可靠性，在此基础上构建安全抽象层。观察嵌入式hal甚至极端的embassy项目，其价值便显而易见。若完全不进行抽象化处理，我完全认同Rust编写体验确实糟糕。
Rust语言在unsafe上下文中的安全保障与C或Zig语言同样可靠，前提是使用了适当的机制(原始指针、MaybeUninit、UnsafeCell/Cell、用于空值的Option、Pin
<>等)。有时标准库代码会不必要地增加难度——它们要求所有操作都符合普通安全Rust的严格规范，而非接受更宽松的输入(例如可自由别名的&Cell<T>)，但这类问题发现后即可逐一解决。我的观点是：编写正确的Zig代码比编写正确的Unsafe Rust更容易。Rust中原始指针可能为空，因此应使用NonNull
<T>，但其别名规则极易出错。此外如你所言，标准库的兼容性也存在困难。当能在安全用户空间编程时，我其实并不介意Rust，但在嵌入式项目中，Zig给我带来了更好的体验。
虽然内存安全很重要，但我并不认为它突然变得如此重要，以至于必须不惜一切代价快速解决。还有更紧迫的问题需要处理。我也完全不认为C/C++是死胡同。事实上，我认为通过逐步改进来提升C和C++代码的安全性，远比引入新语言更具成本效益。原因在于，复杂性与长期维护负担才是自由软件的核心痛点，而Rust反而加剧了这一问题。典型例证是：依赖链中某个Rust视频编解码器导致的安全更新受限，对我的安全威胁远大于它可能预防的内存安全问题：https://www.debian.org/releases/trixie/release-notes/issues.. ..我认为这正是人们忽视的关键。他们过度夸大内存安全的重要性，却忽视了那些看似琐碎却实际更为重要的核心问题。我从未见过有人直接因内存安全引发的安全问题受影响，却见过许多因软件未及时更新而受害的案例。
英文链接：https://www.debian.org/releases/trixie/release-notes/issues….
> 当前Debian基础设施在重建系统性使用静态链接的软件包时存在问题。随着Go和Rust生态系统的扩张，这意味着在基础设施得到改进前，这些软件包将只能获得有限的安全支持。
C和C++语言在内存安全方面“渐进式改进”的现实方案有哪些？
我的第一反应是这类似于讨论Java中手动内存分配的渐进式改进。C和C++本质上存在内存安全隐患——这是其设计初衷，旨在通过直接简洁的方式提供对内存的完全控制权。
> 我认为Rust存在严重缺陷，所谓“现代”更多是个人偏好。
真的吗？难道C或C++(作为Rust的主要竞争语言)就没有问题？当然偏好影响一切，但我认为很多人选择Rust是因为它确实是更优秀的工具。
我理解开源软件受企业利益控制的担忧，但这与Rust作为语言的优劣是两个独立议题。
数十年前Ada和SPARK就实现了安全系统语言的承诺，且避免了Rust多数缺陷。Rust固然有其优势，但绝非唯一选择。GCC编译器同样内置Ada编译器。
问题在于它们忽略了语言的易用性，导致其局限于安全关键场景的封闭生态(而Rust的认证分支正开始蚕食这块市场)
若您指的是认证Rust分支Ferrocene，容我稍作更正：我们并不视其为真正分支，而是Rust项目编译器的下游分发版本。编译器本身变更甚微，主要更新集中在文档、构建流程及测试覆盖率——我们测试了上游未覆盖的架构。
确实用“分叉”这个词不太准确，抱歉。
你觉得Ada语言哪里难以接近？
初看之下它完全像外星语言。我真正接触Ada的契机是这篇将它与Rust对比解决Advent of Code的博文[1]，但阅读时那种感觉就像在看Haskell代码(虽没那么极端)。虽然我并未真正给它机会，但其用户群体比Rust更小众，所以难以评判。它确实具备很酷的特性(能定义n位数据类型很棒)，但更偏向命令式编程的倾向也让我提不起兴趣。
[1] https://github.com/johnperry-math/AoC2023/blob/master/More_D…
这些错误具体指什么？
Ada似乎必须强制添加内存安全机制——SPARK就是这么做的——而它倾向于面向对象的特性，未必比Rust倾向于函数式编程的优势更明显。
你指的是类型推断这类特性吗(因此Rust代码可能不够清晰，因为类型不总是显式写出)？
还有最近的Modula-2。
这其实是种“微妙的反驳式辩解”……
要知道，GP并非相对论述，而是绝对论断：他们认为Rust存在问题。他们并未暗示编程语言的问题本质上可互换，也未主张应汇总所有问题、比较不同语言、从而评判优劣。
我对Common Lisp编写高速代码非常满意。
当然多数人不够聪明掌握这门语言，只能使用Rust这类次等的Algol语言。
不必用这种精英主义玷污Common Lisp。任何需要天才才能使用的语言都是糟糕的语言。这正是C语言的核心缺陷之一。我们终究是时而犯错的凡人，而 一次 未定义行为就足以打破语言给出的所有保证。
我发现高门槛语言反而更令人愉悦——毕竟像楼主这类人根本看不懂，自然不会有人试图用“正确方式”来胁迫我们。
此人曾发表如下言论：
——此言出自上班时间。
> 毕竟像楼主这样的人根本看不懂，更不会有人来欺负我们
是啊，真高兴听说那里没人欺负人！
我通常不赞同刻薄言论，但…说得好。
精英主义本身就是一种欺凌，必须予以同等对待。
我对人类群体并无特殊好感，但也竭力避免对他们抱有精英主义态度。虽非总能成功，但我始终努力践行——家人教导我尊重所有人，即便个人并不喜欢。
欣慰你理解自卫的本质。
请列举另一种语言：既能像Rust般提供内存安全与确定性运行时保障(彻底消除特定类别的漏洞)，又能实现与现有C代码的无缝集成，同时拥有Rust这般活跃的社区与热情的贡献者群体。
我等着。
反对意见源于这种观念：仅仅因为技术可行，就要用新语言重写所有旧工具。比起创建新项目使用新语言，大多数Rust项目更像是旧项目的改写。过去一年你在黑客新闻上看到的那些“我用Rust重写了XY”的项目，如今大多已弃置。这不过是种潮流——为学习语言而用Rust重写现有工具，随后便将其投入实际应用。
[已删除]
对我而言，关键确实在于语言本身。虽然有时略显强硬，但我认为用更安全的语言重写某些工具的论点有其道理。至于apt工具链是否该重写，我留给Debian开发者决定；但对于解压工具，我确实能看到其优势。
若Rust成为首选语言，我宁可避免。其语法糟糕，语言复杂，且Rust程序的依赖收集速度堪比JavaScript。我认同的是Rust确实吸引特定类型的人才——他们能编写绝妙软件，但如同Rust编译器般，对输入内容极为挑剔。
归根结底，我并不在乎apt用什么语言编写——毕竟代码不是我写的，我只是使用者。真正令人遗憾的是，某些平台可能因Rust开发者漠视其价值(而非平台本身过时)而被抛弃。
> 虽然有时显得有些强硬，但我认为用更安全的语言重写某些功能的论点确实有道理。
是的。就是这样。写出代码，向我们证明它很好就行。
讽刺的是，那些讨厌它的人(通常没有任何技术论据)反而显得更像教派信徒。
至少在我这个没用过Rust的人眼里是这样
别跟我说你没用过Rust，却又不肯承认你没用过Rust。
> 我不太理解人们为何抵制内存安全语言
据我在HN上所见，唯一被讨论的内存安全语言只有Rust，而且多数支持者提出的理由都幼稚可笑。
Java和C#是内存安全的语言，常见的解释型语言如Python和Ruby也是如此。甚至JavaScript也具备内存安全性——除非存在可能实际影响这种安全性的微妙JIT漏洞。
但楼主指的是无需垃圾回收器或运行时环境就能实现内存与数据安全的语言，这样才能作为系统编程语言使用。不知为何，人们总只讨论Rust在这个领域！
目前除Rust外，尚无其他广泛使用的编程语言能在不依赖垃圾回收器的情况下提供同等内存安全保障。我认为这种现状不理想，希望更多人能开发内存安全的系统语言，像Rust那样探索设计空间的其他维度。但就现状而言，Rust已相当出色，无疑优于C或C++。
Swift在某种意义上也具备内存安全性。
它具备广义意义上的垃圾回收机制。
Swift采用自动引用计数(ARC)，这属于垃圾回收的一种形式。
现在我很好奇，它是否会回收内存循环？
编辑：简单搜索后发现：不会。
不明白为何被负评，引用计数绝对属于垃圾回收范畴，即便不是追踪式回收。
即使现代C++在正确使用时也具备内存安全性。
按这个定义，所有语言“正确使用时都是内存安全的”。
嗯…确实。哈哈
这种说法并不严谨，因为内存安全是语言本身的属性。代码本身可能存在安全隐患(即不正确)，但这是另一个问题。
所谓语言层面的内存安全，意味着不存在任何可能导致“不安全操作”(对Rust而言即未定义行为)的函数误用或对象错误使用场景。
换言之，其默认状态是安全的，同时提供逃逸机制。而C/C++等语言的默认状态则是危险的。
另需补充：程序正确性与语言安全性、代码安全性是三个独立概念——即便使用不安全语言编写存在漏洞的代码，最终生成的二进制文件仍可能完全正确。
我也是直到在HN之外的社交媒体看到关于Linux中Rust的评论才知晓此事。
显然，Rust已被纳入“觉醒议程”
没错，我注意到许多提及内核中Rust或Rust本身的视频下，评论区极可能直接搬运自4chan政治版或类似平台
这背后有何特殊原因？难道他们比常人更反对行为准则？
完全反对行为准则及其倡导者的典型政治倾向。还有纯粹的逆向思维精神。
这种说法虽然粗鄙且政治不正确，但你难道不觉得其中有些道理吗？
当你选择投入门槛高、耗时大的编程语言时，自然也选择了围绕该语言形成的现有社群——因为潜在贡献者、技术支持者，以及推动语言生态发展的关键人物都来自这里。反过来，社区自然会将自身价值观和审美偏好灌输给你——无论是主动利用相对优势施加影响，还是通过潜移默化的渗透。恰巧Rust社区确实由美国进步派主导，这不足为奇：毕竟该语言诞生于一家美国公司，其员工曾因CEO言论触犯进步派敏感神经而扬言造反。
因此，将Rust引入项目后，它逐渐变得更“觉醒”实属自然，正如使用Ruby更可能吸引日本贡献者，或支持Baikal处理器会让你被纳入俄罗斯生态圈。觉醒派自身对此效应心知肚明，这正是他们对Framework将Omarchy推为Linux发行版感到不安的原因。
当然，我们需要质疑将单纯的预期效果称为“议程”是否公平——这无异于暗示存在预谋。考虑到文化战争中无休止的自我沉溺，若世上真无人提出上述观察，甚至有人认为推动Rust采用[也]是件好事，正因为 如此，我反而会感到惊讶。因此，Rust的采用在某种意义上确实成为“觉醒议程”的一部分，正如拒绝Rust——或许更为明显地——成为“愚昧议程”的一部分。
> 因此，将Rust引入项目自然会使其逐渐变得更“觉醒”，正如使用Ruby更可能吸引日本贡献者，或支持Baikal处理器会让你被卷入俄罗斯阵营。觉醒派自身对此效应心知肚明，这正是他们对Framework推广Omarchy作为Linux发行版如此不安的原因。
我认为这种分析基本准确——其中既无阴谋论也无刻意操纵，只是Rust社区(至少目前)恰好聚集了大量美国进步派人士，其中许多人公开致力于在关切领域推行美国进步派意识形态规范(这正是“觉醒”一词的核心内涵)。
我认为Rust是优秀的软件工具，希望它能像C语言那样广泛普及且保持政治中立，被各种议程(政治或其他)的开发者应用于各类项目。因此我期待那些不认同美国进步主义规范的人士和项目采用该语言并成为活跃用户，这将有助于稀释Rust用户中的进步主义者比例。我本人并非美国政治进步派，且对许多知名Rust开发者的公开政治立场存在诸多异议。
这种情况还在持续吗？疫情期间人们对某些政治议题相当激进，但除了Rust Discord里某些兽迷外，我没注意到其他明显的政治倾向？
虽然不清楚如何衡量，但我认为使用该语言的人及其偏好本就不该有改变的必要？快速检索发现他们似乎 非常 近期才将主分支重命名为“main”(https://blog.rust-lang.org/inside-rust/2025/10/16/renaming-t…) (背景：https://sfconservancy.org/news/2020/jun/23/gitbranchname/)，这让我更惊讶的是此举竟未更早实施。
我认为开源政治的整体温度并未明显降低：仅就登上Hacker News的事件而言，过去一个月左右我们就目睹了前述关于dhh (Ruby on Rails的领袖？创始人？)及其项目的争议，以及NixOS董事会与社区版主之间的控制权之争——后者以推行政治清洗著称，并试图对前者行使正式管理权。
我们需要更有效的机制来防止机构被意识形态劫持，尤其当机构使命(如推广Rust语言)与宗教、政治、性取向或道德观毫无关联时。
阅读充斥偏见形容词的编程语言评论纯属浪费时间。我选择跳过这类社交媒体内容。
人们(可以理解地)厌倦了这样一个事实：无论出于何种原因，Rust语言最狂热的支持者们都令人难以忍受。
就我个人而言，真正困扰我的是这样一个事实：Linux平台上Rust语言的(其中一位？)最具代表性人物，以及“Rust Forever”组织的核心成员，竟在我国境内传播并鼓吹非法色情内容，却未受到社区的任何问责。
据我所知，唯一对此发出警告的群体是一个充斥着刻薄小人的论坛——他们耗费数周在网上搜集讨厌对象的黑料。似乎没人敢触及这个话题，生怕被贴上他们的标签。
我承认，现在确实不是个好时机。
我实在不确定你指的是谁，也不确定这是否准确反映了他们的观点。说到底，我甚至不清楚你身处何国，更不知自己是否认同该国针对此类色情内容的法律。毕竟许多我未曾居住且毫无关联的国家，其法律中存在我反对或经常违反的内容。
我对要求社区追究个人责任的做法相当怀疑，尤其当这个社区只是松散的群体——成员主要在线交流，仅因使用特定编程技术而聚在一起；他们很可能在其他各种议题上存在分歧，包括争议性话题。
> 在我国属于非法的色情内容，却未受到社区问责
某类言论在你的国家非法，并不意味着它在全球都应被禁止，也不代表其本质错误，更不要求全球社区遵循你国家的特定标准——即便该国是美国。
换言之，没人该在乎开源开发者的色情偏好。
> 个人而言，我单纯介意的是——这位在Linux平台推广Rust语言的知名人物(之一？)竟在社区毫无问责机制的情况下，消费并鼓吹在我国属于非法的色情内容。
你对他人个人品行的厌恶情绪，在技术讨论中毫无立足之地。
你在指谁？真心想问，此前从未听闻相关争议
某Linux移植到Mac项目的(已退休？)负责人。我刻意避免点名，并非故弄玄虚，而是考虑到许多人会通过搜索偶然看到这类帖子——或是负责审核的人员。我虽不认同这种做法，但理解其便利性。
请别在讨论中使用带有偏见、挑衅性，更重要的是无关紧要的术语。这毫无助益，对谁都不利。
反对声浪针对的是信徒群体而非语言本身。
若能将语言与信徒群体分离，它本应获得更快的普及。
所谓信徒，就是那些积极分享语言使用体验并宣扬其优势的人群。所以持正面观点者应保持沉默，而负面评价者却可自由发声？你竟认为这会加速推广进程？
这想法倒有意思。虽与人类本性背道而驰，但确实耐人寻味。
Rust在普及度上已相当成功。它支撑着互联网的重要部分，被三大操作系统(Windows、Linux、Android)采用，众多跨领域成功企业用它构建了完整技术栈。以crates.io下载量衡量的采用率过去十年每年翻倍。
现在我忍不住想象：若当年他们采纳你“永不正面评价”的远见卓识，Rust的普及程度会提升多少。
> 所谓信徒，指那些积极分享语言使用体验并宣扬其优势的人群。
不，指的是多年来催生众多Rust梗图的群体。
我实在想不出其他任何即将主流化的语言会背负如此恶劣的社区声誉。Scala？Kotlin？Swift？Zig？这些语言的社区都未曾建立过如此糟糕的名声。
毕竟多年来，论坛上凡提及C或C++的帖子都会被Rust拥趸搅黄。我从未见过C++用户跳进Rust讨论区发难，却屡见Rust用户闯入C++或C讨论区大肆攻击。
> 这观点耐人寻味。虽与人性认知相悖，却仍值得玩味。
事实上，Rust在此样本中属于特例就说明了一切：其他新兴语言过去从未获得过如此声誉。
> 我实在想不出其他任何即将主流化的语言曾背负过敌对社区的恶名。
要么是你太年轻，要么就是你没经历过2010年Go语言初露锋芒的岁月。当年同样闹得沸沸扬扬——有人赞叹“这语言真实用”，随即引来“人类文明末日降临”的抨击。它当时的声名与你描述的如出一辙(“DAE泛型？？”)。
最终这些批评者转向了新的攻击目标。Rust的批评者也会如此。当Zig达到1.0版本并获得更广泛应用时，批评者们必将卷土重来。
> 因为你太年轻，或者你没经历过2010年Go语言初露锋芒的时期。
我从90年代中期就开始从事程序员工作了
>> 我实在想不出还有哪门即将主流化的语言，会背负着敌意社区的恶名。
> 有人说“我喜欢这门语言，它相当实用”，紧接着就会引来认为它将导致人类文明终结者的滔滔不绝。
那又怎样？这和存在敌对社区是两回事。我从未见过Go支持者闯入C#或Java讨论区攻击这些语言的开发者，就像我经常看到Rust支持者闯入C或C++讨论区，把开发者骂作恐龙、无能之辈等等。
> 这和存在敌对社区是两回事
敌对的标准由谁来定？或许是那些憎恨者吧。当年Go社区肯定也被憎恨者贴过“敌对”的标签。
看看Linux维护者制造的闹剧——他们疯狂敌视、提出无理反对、表现得极其无礼，甚至让林纳斯都忍无可忍。而Rust for Linux成员始终保持着尊严，Linux子系统维护者却像幼儿园小孩般行事。
当然，仇视者读到同样的邮件时，确认偏误会让他们认定自己正确，把问题归咎于Rust。
继续仇视吧。
老兄，本帖楼主在多条回复中公然诋毁C语言程序员。Rust社区的声誉很大程度上由推广者塑造。若遭遇抵制，不过是这种行为的必然结果。
我还注意到这些语言之争具有鲜明的代际特征，由此衍生出两点影响： 其一是资深开发者更具抗压性；其二是他们对Rust的宏大承诺持更审慎态度。无论你是否认同，对经历过类似情况的资深开发者而言，Rust的推广策略在他们眼中充斥着天真色彩。
编写设备驱动程序必须直接操作内存，操作系统内核的定义就要求直接管理内存。学术界对内存安全语言的研究成果参差不齐，大量实验最终归零(即无法实现)。然而Rust团队仍将其奉为“唯一正道”。与此同时，当前多数Rust开源项目已遭弃置。
这并非偏见，而是基于过往教训的警示——我们不愿重蹈年轻时因经验不足而犯下的错误。你执意重蹈覆辙的决心，在旁人眼中绝非你自认的“觉醒”。
请看Android团队这项研究中的“无效结论”——《从源头消除内存安全漏洞》(https://security.googleblog.com/2024/09/eliminating-memory-s…) (https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?m=1))。他们停止添加新的内存不安全代码后，内存安全漏洞数量急剧下降。如今他们仅用Kotlin或Rust编写新代码。
Android团队为数十亿用户交付了更安全的操作系统。选择更多Rust和Kotlin、减少C++的使用，让他们的生活变得更好。
> 编写设备驱动程序时无法避免直接操作内存。
这并非你想象中的陷阱。请查看这个已提交的上游驱动程序 – https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin…
这是支撑Android所有进程间通信的成功内核驱动程序。作为Android系统中承受最大负载的组件，它尤其需要抵御恶意软件的持续攻击。事实上，它对内存的操作完全没问题。
你急于否定Rust时，并未对其进行技术评估。若曾评估，就不会将内存安全与缺乏内存操作能力混为一谈。你采取了思想懒惰的捷径——因新事物不可能超越旧事物而全盘否定。
我写下这些并非为了改变你的想法——我认为这不可能。我写下这些是为了让其他读者避免陷入你的思维误区。我无需说服你，因为这个行业无论如何都会向前发展。
> 相信当年Go社区也被批评者称为“敌意社区”。
我亲历过那个时代，事实并非如此。Go社区从未在各类编程讨论中跳出来指责他人是恐龙、缺乏安全意识等等。
> 我没见过C++用户跳进Rust讨论帖发动攻击
绝对存在，且由来已久。这或许是某种反应。我不想争论谁先挑起的。
我同意你的观点：若Rust社区真有如此特立独行的声誉，其中必然存在合理缘由。
从外部观察，反对Rust的声音大多属于“我年纪大了，从不犯错，职业生涯后期不想学新东西”这类类型。
我很少见到反对Rust的论点能提出切实可行的替代方案来解决Rust倡导者试图解决的问题。这不过是一群老家伙让完美成为好的敌人罢了。
我觉得你最后一句说反了。因为字面意思是，你认为我们现在拥有的东西已经完美无缺。如果真是这样，转用Rust就是浪费时间。
不，我觉得有道理。完美并非指现状(除“技术问题否认派”外众所周知)，而是指C/C++或新语言通过增强功能达到Rust水平，同时避免后者的特殊性。
> Scala？Kotlin？Swift？Zig？这些语言的社区从未建立过如此糟糕的声誉。
> 我没见过C++用户跳进Rust讨论区发攻击帖，但Rust用户跳进C++或C讨论区发攻击帖的例子比比皆是。
Zig就让我见识过这种事。甚至无需语言社区作证。看看整个讨论串吧。照照镜子。每当Rust在HN被提及，反Rust教徒就会来抱怨“怎么还有Rust存在”。
即便有人只是发帖说“我用Rust做了这个”——这帮人就会跳出来抱怨“你为什么要提Rust？！”。好好照照镜子吧。谁伤害过你们？
> 照照镜子吧。
指出Rust社区声名狼藉而其他社区并非如此，竟需要“照照镜子”？
根据我在这些讨论串的观察，抱怨Rust“信徒”的人比真正的信徒更污染讨论氛围。
Rust的仇视者们似乎有着奇怪的执念。
> Rust的仇视者们似乎有着奇怪的执念。
这不就是绝佳例证吗？抱怨社区的人被贴上“抱怨语言本身”的标签。
你难道没看出问题所在吗？
我觉得你需要回答自己的问题…为什么把“Rust仇视者”解读为“Rust -语言 仇视者”，而非“Rust -社区 仇视者”？
> 我觉得你需要回答你自己的问题…为什么把“Rust haters”理解为“Rust语言的仇视者”，而不是“Rust社区的仇视者”？
因为原文明确写着“Rust haters”，而非“Rust社区的仇视者”。
你是说当人们提及“Rust”时，指的是社区而非语言本身？
是的，你理解了一半。
若改为“Rust社区的仇视者似乎异常痴迷”，表述依然成立。
> 若改为“Rust社区的反对者似乎异常执着”，语义依然成立。
或许吧。但这与Rust社区相较其他社区声誉不佳有何关联？
Rust语言与Rust社区密不可分。这是语言设计者的刻意选择
> 若能将语言与信徒群体分离，其普及速度本可更快。
好消息：这完全可行。正因如此它才实现了快速普及。
(那些以“梗文化式”推广Rust的人，通常并非实际开发Rust编译器或核心生态系统的团队)
我认为这是推广Rust的错误方式。对我而言Rust只是炒作。我认识的人中无人编程或考虑过Rust。我来自嵌入式领域，那里C语言依然称王。我理解有人会视Rust为良好替代方案，但只要真金白银仍在C语言领域，它就尚未准备就绪
> 我认识的人里没人用Rust编程，甚至没人考虑过它。
仅因你在特定领域不认识使用者就断言无人使用，这种推论并不合理。我认识许多使用Rust的嵌入式程序员。
Rust在嵌入式领域同样表现出色，我认为这是其核心优势之一。但由于厂商支持缺失且开源库通常不够完善，每块硬件都需要大量基础工作。若你的要求是“仅使用该领域最主流的语言”，这无可厚非——但如此一来评估其他语言便毫无意义，结果早已注定。
我认为相关要求、市场炒作以及Rust官方宣传都存在误导：它并非仅以内存安全为卖点的单一功能语言，而是整体优秀的语言与工具集。
残酷的现实是：若要在嵌入式系统中使用Rust，几乎所有驱动程序都需从零编写。既无OEM驱动支持，如你所言开源驱动也尽是垃圾，专为Arduino级业余项目编写。
对于中小型团队或需使用复杂外设/SoC的场景，驱动缺失是致命缺陷。反观C语言，任何MCU、嵌入式SoC或中等复杂度外设通常都附带C语言驱动代码。
我不太理解：Rust在C语言互操作方面表现出色，为何不直接使用OEM驱动/SDK，再通过Rust绑定到自己的代码中？这正是我每次在Rust中需要调用C库时的做法。
因此，有时无法实现的主要原因在于你使用Rust的方式。例如，我目前倾向于采用基于异步的Rust Embassy生态系统，其驱动程序需要与嵌入式异步层(embedded-hal-async)进行深度集成——这通过C语言绑定实现绝非易事。
实际操作中我往往重写驱动程序。听起来很吓人，但实际操作通常比人们想象的简单得多，最终代码量通常只有原始C代码的1/4甚至更少。如果只实现所需功能，有时驱动程序的Rust代码甚至不足100行。
这是我之前未曾考虑过的场景，谢谢！
嗯，你提得有道理。我曾在标准Rust应用中做过些C语言FFI适配，但没想过将其应用于嵌入式领域。我用Rust嵌入式封装过CMSIS-DSP(ARM官方DSP工具包，含滤波器等)，效果很好！虽然编译时间增加，但值得。或许我们该更广泛地推广这种方法。
存在一个问题：将绑定生成器提供的指针级API转换为包含引用、数组等的高级Rust API相当繁琐。每实现一项功能都需要编写大量模板代码。对特定应用影响不大，但构建通用库时并不理想。C库对整数类型的处理往往不够严谨，虽然能用，但不符合Rust的编程规范。或许能通过代码生成或过程宏实现自动化？
我认为ESP-IDF的Rust库主要采用FFI(？)，这或许是个好例子。我们在STM-32和Nordic支持方面一直在重复造轮子。
> 我不太理解：Rust在C语言互操作方面表现出色
Zig才是C语言互操作的典范——而非Rust。
而且Cargo在嵌入式生态中反而构成障碍而非助力。
之所以到处出现“重写成Rust”的呼声，恰恰 是因为C互操作性太弱，无法轻松实现分步改造。
更别提Rust的编译时间、调试器中查看Rust代码的体验，以及调试模式下Rust代码的糟糕表现…
我对Zig没有强烈立场。但有明确的 实证 表明Rust的C互操作性是成功的[1][2][3]
需注意：浏览器属于 病态 案例——涉及构建系统集成、全局状态假设、C++等复杂因素。
(你提出的其他问题有其合理性，在我看来并非无理取闹。但实证表明这些并非阻碍Rust互操作性的因素。)
[1]: https://chromium.googlesource.com/chromium/src/+/refs/heads/…
[2]: https://firefox-source-docs.mozilla.org/build/buildsystem/ru…
[3]: https://www.memorysafety.org/blog/rustls-nginx-compatibility…
https://github.com/avr-rust
https://github.com/esp-rs
https://github.com/rust-embedded/cortex-m
就连嵌入式领域也在悄然变革。
那是你。在微软和谷歌这类公司，有大量人思考和讨论Rust，已有部分产品/功能采用Rust。
在微软，确实有很多人思考和讨论过C#，也有产品/功能采用它。并非它消失了，只是未能赢得广大(软件开发)公众的心。
这和我评论有什么关系？你的回应毫无逻辑可言。
> 我认识的人里没人用Rust编程甚至考虑过它
这纯粹是你的偏见。我认识大量使用Rust的人和公司。你的设备很可能正在运行Rust程序。
我思考Rust，我用Rust编程。现在你总该认识做这些事的人了吧。
AWS内部核心服务大量采用Rust。
EC2(服务器端大量嵌入式工作)、IAM、DynamoDB以及S3的部分组件，多年来都深度使用Rust。
相较于C语言，Rust能让我们实现更快速的开发，同时相比其他语言还能节省大量计算资源和内存。目前遇到的最大问题是二进制文件体积——这对嵌入式领域至关重要。
Linux现已支持Rust开发。我认为Rust未来取代C语言的主导地位已毋庸置疑。
据我所知，在FAANG巨头中，AWS可能是Rust应用最广泛的。我们雇佣了大量Rust核心开发者(包括担任高级工程师的Niko)，目前内部对Rust的支持力度非常强：)。在性能无关紧要的场景人们仍会使用JVM，但凡涉及性能优化的领域，我认为现阶段内部已无人能获得批准用C替代Rust。
我也是嵌入式领域的。我们在某个项目中尝试使用Rust，最终得出结论：将团队从经验丰富的C++开发者转型为初级Rust开发者毫无意义。更棘手的是，Cargo引入的依赖包数量几乎无法管控——仅一个小型工具的二进制文件中，就存在三个不同版本的相同库作为依赖项。
更糟的是，部分团队成员对用Rust编程毫无兴趣。
最终我们彻底废弃了该工具，给项目造成了巨大时间损失。
完全可以不依赖Cargo使用rustc编译器，在嵌入式领域这样做其实有充分理由。
能否推荐不依赖Cargo使用rustc的示例？
我虽反感传教式的说教和反C语言的态度，但并非反Rust。我特意购置了内存超标的电脑，部分原因正是为了尝试Rust开发。然而从零开始编写、编辑和编译小型程序时，若完全避开Cargo，过程异常艰难，宛如逆流而上
可以推断，那位嵌入式程序员无法确定如何避免使用Cargo并引入不必要的依赖。否则他不会遇到这个问题
确实逆流而上；但并非不可能
例如Chrome和Fuchsia都使用现有构建系统编译内置的Rust组件。
Bazel和Buck2相对而言都能很好地配合Rust工作。
开发者也可严格遵守Cargo规范：不添加冗余依赖，对已引入的依赖保持警惕并监控其传递性依赖。
个人认为这更多是crates.io的问题而非Cargo本身，也是语言社区最大的弱点。遗憾的是，多数开发者来自使用NPM的背景，因此在理念上未能…敏锐察觉…此处的症结所在。
大量工具依赖于Cargo，例如LSP、分析器等。
一旦移除Cargo，Rust的开发环境将变得相当贫瘠。
这种“语言需要生态系统支撑”的说法实在令人反感。真正的整合点应当在链接器层面，而非体现在导入外部依赖、模块封装、源代码托管方案、调试器选择等环节。
遗憾的是，Rust的工具链正是如此设计的。在多数生态系统中(即便不是全部)，我确实认同你的观点。
这并非宣传噱头。该功能确实存在，代码已实现，开发团队已决定将其发布。
其次，所谓“因你所在领域不用就禁止操作系统开发使用”的论调纯属无稽之谈。
> 我认为这是推广Rust的错误方式
这种视角完全错误。这只是有人想为特定目的使用Rust，而非某种宣传噱头。
> 我认识的人中没人编程或考虑过Rust。我来自嵌入式领域，那里C语言依然称王。
现在该走出你的舒适圈了，别再把自己的小圈子当成整个世界。
> 只要真金白银还在C语言领域，Rust就不算成熟
过去十年里，真正的利润其实来自JavaScript和Python。嵌入式岗位通常比Web开发更少且薪资更低。在C语言重新崛起之前，难道它也不算成熟？
> 这完全是错误的视角。
告诉那些无法维护完整编译器后端的开发者“卷蛋走人”，对于Debian这样的大型发行版而言，这种立场堪称“耐人寻味”。
仅仅是解析文件？
光是解析文件已有现成工具库可选，更何况是为提升安全性而做——这根本没说明具体威胁模型。
我主要用Python、C、C++、JavaScript和Rust编程，包括嵌入式系统(C/C++/Rust皆适用)。
如今批评Rust的人大多基于“有人想要这样改变，所以它就是坏的”这种文化偏见，而非基于技术本质。
Rust是优秀的语言，其设计中融入了顶尖C程序员内化的经验。若你是顶尖的C程序员，本就会手动执行许多Rust自动强制执行的规则。这并不意味着Rust是牢笼——你随时可以选择unsafe模式。
但若生命攸关，我宁愿用Rust而非C编写程序，尤其涉及并发或多进程时。
在嵌入式领域，实际问题在于现有库大多用C或C++编写。这或许是日常开发中不选择Rust的原因，但绝非评判语言优劣的合理依据。每种编程语言最初都只有一个用户，每种语言最初都缺乏自身生态的依赖库。Rust在跨语言协作方面表现卓越，其工具链也相当完善。Rust的编译器错误信息让其他语言意识到自身错误提示有多糟糕。
即便无人使用Rust编程，该语言的优秀特性仍能提升其他语言的质量。
> 存在一种文化倾向：“有人想要这样改变，因此改变本身就是坏事”。但从未基于实质价值进行讨论。
在此思维模式下，反对变革本身就是基于价值的论证。因为你投入时间做任何事，都意味着放弃其他可能投入时间的事物。
没错，但你也得正视对方的论点。对方主张重写是值得的，因为它能杜绝整类内存泄漏问题——这类漏洞至今仍占据可利用CVE列表的前列。
我们或许可以假设他们的立场是：“噢，我们有了这门神奇的新语言，它能让一切变得百分百安全，因此必须重写所有代码。”但事实并非如此。多数人深知重写永远是权衡取舍——旧漏洞可能卷土重来等等。
正如我所言，我同时掌握两种阵营的编程语言。若 我 需要编写并维护关乎性命的安全软件，我必然选择Rust。内存安全只是其中一小部分优势，更关键的是严格类型系统(可强制执行某些保证，防止贡献者轻易搞砸)和工具链(内置测试功能堪称卓越)。
工具链的未来将由新一代开发者青睐的语言书写。曾几何时C++甚至C语言都是闪亮的新星。为何不能像旧时代那样用汇编编写所有软件？因为C语言确实具备切实优势，这才是真正有能力完成工作的人们的选择。
我并非主张所有场景都该重写为Rust，但若某项目近十年的CVE漏洞中，半数本可被原生Rust编译器规避——这难道不是理性之选？
> 但只要真金白银还在C语言里，它就还没准备好
兜售垃圾代码者，其价值仅限于制造垃圾本身
当Rust通过MISRA认证(或建立自有MISRA规则)时，局面或许会改变。姑且称之为美好愿景吧。
(同样地，至今我尚未见到任何令人信服的论据，足以克服Rust这种笨拙冗长又令人抓狂的语言特性)
从未尝试移植 LLVM。将 LLVM 移植到新架构并达到生产级质量，6 个月是否合理？
能否通过使用 Cranelift 后端在不依赖 LLVM 的情况下运行 Rust？
我的意思是，那封邮件明确要求开发者在 6 个月内完成 Rust 移植，否则就终止 Debian 移植项目。
我想问的是前者是否切实可行
据我所知m68k架构已有某种可用的Rust编译器，尽管它不属于默认Rust编译链。我认为将该分支打磨成能正常运行和编译的版本是可行的。
至于Rust当前未支持的其他架构，我认为实现可能性很低。这些CPU架构本身早已淘汰，多用于工业领域，业余爱好者接触到的概率微乎其微。
仍在使用这些老旧架构的用户(除发烧友级黑客外)大概率不会采用Debian Trixie，即便使用也能找到替代方案。毕竟.deb格式本身不会改变，旧版apt和dpkg仍能长期兼容。
既然如此，非m64k架构的“6个月”截止期限根本是虚设。
我认为这属于被动攻击或侮辱性言论
这会让嵌入式Linux Debian镜像体积膨胀多少？
实际增量可能微乎其微，因为镜像无需包含Rust工具链。
虽不确定Rust编译器是否生成更大二进制文件，但单个程序的差异可忽略不计。
不如直接用Fil-C编译包管理器
无需任何改动。在特殊端口上部署Fil-C工具链的工作量，可能比部署Rust工具链更少。
Fil-C确实 很棒，但目前比Rust更棘手——它仅支持amd64架构，且仅由一位天才维护者负责。
这同样不利于吸引新贡献者。自从我们在Ubuntu中改用rust-coreutils和sudo-rs后，社区贡献量呈现惊人增长，这让我深感推动APT融入社区空间具有重要意义。
目前APT的大部分工作都由我熬夜完成，或是利用周末和两周的圣诞假期推进。其次耗时的是工作时间内完成的任务，不过这些内容就没那么酷炫有趣啦 😀
将Rust引入APT只是其中一方面；另一项可能更为紧迫的需求是重写所有APT文档。
当前APT手册页分散在apt-get、apt-cache等条目下，仅在apt(8)中有概览——我们应将其拆分为apt install(8)、apt upgrade(8)等独立文档。同时，DocBook XML对贡献者缺乏吸引力，改用Sphinx框架的reStructuredText有望吸引更多人参与。
> 因为它仅支持amd64架构
抱歉重复回复，但这恰恰是支持Fil-C的关键论点。
若为APT采用Fil-C，可实现可选部署——仅在配备Fil-C编译器的端口上启用。您的APT代码在Fil-C环境中的运行效果将与Yolo-C完全一致。实现起来并不困难。我“移植”到Fil-C的软件约半数可直接运行，而需要修改的情况，其变更内容完全可提交上游，从而同时维护Fil-C和Yolo-C版本。
因此采用Fil-C，就无需强迫移植维护者支持新工具链而引发矛盾！
据我理解，Fil-C改变了系统的ABI，因此在Debian术语中需要创建新架构，例如amd64fil。然后你需要使用multi-arch机制在适用场景中引入amd64fil二进制文件。
具体实施效果尚待观察，但这并非真正的即插即用方案。
> 毕竟当前仅支持amd64架构，且仅由一位天才维护。
这很容易解决。
> 这种情况也不利于吸引新贡献者。
我不理解这点。
> > 毕竟目前仅支持amd64架构，且由单人维护。 > 这很容易解决。
和修复Rust在其余4种架构上的兼容性一样容易吗？
> > 这也不利于吸引新贡献者。 > 我不理解这点。
C++吸引的开发者本就不多，Rust的吸引力要强得多。我渴望更庞大的社区，尤其是年轻群体。不想永远独自埋头苦干 😀
> 像修复Rust支持剩余4种架构那样简单？
更简单，因为你无需为在amd64上使用Fil-C而将其移植到所有架构。
> C++吸引的开发者不多，Rust吸引的更多。
C语言在TIOBE排名第2。
C++在TIOBE排名第3。
Rust在TIOBE排名第16。
所以我不明白你在说什么
他只是根据经验说，将项目迁移到Rust后获得了许多新贡献者。
C(++)在TIOBE排名靠前固然不错，但若他们不参与贡献，这又有什么意义？
先生，请专注于一种不是移动目标的语言。
而关于“年轻”贡献者的论调，和你们高层管理层的胡说八道如出一辙。但你可是独立开发者。
经验丰富的工程师不该引领新一代吗？若真想吸引年轻人，干脆放弃Ubuntu改名Gyatt，把LTS改成Rizz。想想多少年轻人会想参与Skibidi 26.04的开发！
Rust吸引的是炒作和炒作者。问我怎么知道的。您想要过路人还是长期社区成员？许多年轻人渴望学习C语言，寻求合适的导师指导和实践项目。这难道不是更有效的投入吗？您是否曾为这些据称无人问津的项目开展过招募？
你不仅犯了错误，还为老板们背了黑锅。艰难时期已至，但或许该坚持寻找比这更好的工作机会。
我赞同此观点。Fil-C确实令人惊叹，而Rust同样可能引发恐慌(若你担心程序崩溃/中止)。
我对Rust的主要反对在于其丑陋的外观。为何非要改变类型和函数的定义方式？我实在厌恶def、fn这类关键词以及其他“显式”函数声明。还有那些从C++继承的::和
<>符号。从语言设计角度看，Java和C#在引入新特性时，既保留了C语言的可读性与熟悉感，又做得更好。C语言的“螺旋式”类型声明语法对人类和机器都难以解析。这大概就是连C++都在逐渐摒弃它的原因：
虽然像上文这样的简单示例容易受到批评——毕竟 C++(或 Rust)版本比 C 声明更冗长——但请考虑以下情况：
而符合Rust惯例的等效写法：
后者通过递归解析类型声明即可轻松理解。仅需一瞥便能看出顶级类型是Vec，同时能清晰识别出lambda及其签名。
Rust语法另一项人性化设计在于可直接复制原始类型(无需变量名)：
而独立的C类型则呈现为：
这简直是一团乱麻 😉
此外，我认为C#的类型语法总体上更接近Rust而非C。前例的粗略对应写法是：
不可否认“?”比Rust的“Option”更符合人体工学，但C#的类型系统也远不如Rust或C++表达力强，所以选择你的毒药吧。
> 对整个项目而言，关键在于能够向前发展并依托现代工具技术，而非因将现代软件硬塞进复古计算设备而受制。
…我们讨论的可是 Debian 系统？
…对于那些执意要从“复古计算设备”中榨取实用价值的人，推荐哪些发行版？
…这里讨论的最低配置标准是什么？
若使用Rust标准库倒也无妨，但我不愿看到Cargo为编译这个deb解析代码拉取500个依赖包。
我不在乎内核开发者用C语言还是Rust语言。我用生产环境来评判质量——只要运行良好，构建方式无所谓。
凭什么用生产环境来评判软件安全性？你肯定没像漏洞挖掘者那样使用它。
或者换个角度看：我们集体在生产环境中大量使用C语言，看看那些安全问题就够了。结论已定，质量低下。
我敢肯定很多公司都会在我之前在生产环境中使用它。我问问看就知道了…
最终当非x64或ARMv8+架构被宣判为“复古计算”时，唯有NetBSD能坚守阵地。
能否同时强制要求代码在Valgrind下运行时零警告？
这能省去后续大量麻烦。
这正是APT的目标。当然我们存在覆盖机制，因为需要复制未初始化数据：缓存文件整体分配并在末尾写入，但并非所有区域都会被使用，却会触发相关操作。
若为仅复制可达区域而引入复杂代码既愚蠢又易引发错误。
但请记住Valgrind存在大量缺陷，我们在处理Valgrind误报(非amd64平台)上耗费了大量时间。
坦白说，我调查过的多数“误报”要么是主观臆测，要么源于对实际情况的无知。你似乎在使用Debian系统，这恐怕无济于事。以下是典型的Debian“错误”报告：
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802778
该报告已有十年历史，但从未属于误报。该问题早在数年前就已修复，且修复方案并未涉及压制错误。
Valgrind确实需要大量改进，尤其针对缺失的CPU特性和Darwin平台。据我所知，memcheck的错误大多属于相对冷门的边界案例。
若您遇到错误，请提交至https://bugs.kde.org。
这对内存安全有益，且无需用炒作语言重写所有软件。不，我们不该这么做 😉
有动力的人似乎更倾向于用13年前的编程语言重写。太疯狂了。
依我之见，Rust只有在确定稳定的ABI接口、支持非静态链接并能生成动态链接二进制文件后，才算真正成熟。
这番言论极其坦率，我完全赞同。复古计算爱好者根本不需要运行现代操作系统的能力。
x86版Debian居然还在编译针对奔腾Pro(1995年！)的软件，简直荒谬。
x64版Debian稍显现代，但你必须豪掷千金购买2005年的处理器(Prescott架构)才能满足其海量功能需求。
> x86 Debian居然还在为奔腾Pro处理器(1995年的老古董！)编译所有软件，简直疯了。
需注意Debian自第13版起已不再支持x86架构。
> 令人难以置信的是，x86版Debian至今仍在为奔腾Pro处理器(1995年产品！)编译所有软件。
Debian 13将x86最低要求提升至奔腾4，因LLVM需要SSE2指令集，而Rust语言依赖LLVM编译器。
据我理解，此前目标并非奔腾Pro本身，而是其等效的嵌入式CPU。2005年后服务器和桌面设备本可使用x86-64版Debian。
这难道只是“复古计算爱好”？某些企业可能仍需支持老旧设备，尤其在发展中国家。虽然我不了解实际情况，但我的建议可能确实有些疯狂。
不，这是个合理的问题，随着关于添加此要求的讨论持续，相信未来几天或几周内会得到解答。但某种程度上，这已偏离核心议题。
企业或爱好者维护旧硬件的成本并非零。那些强烈要求新软件持续支持特定平台的群体，其实有诸多选择：推动LLVM和Rust支持这些架构、加速GCC前端对Rust的支持、维护自己的apt分支等等。
发达国家企业运行在老旧硬件上的现象远比发展中国家普遍。二十三十年前，发展中国家基本未使用计算机，除极少数尾部案例外，几乎不存在该时期的随机遗留设备。再者，考虑到2000至2010年代PC与服务器市场的演变，购买当时主流的x86设备远比从海外进口古董级Alpha系统更经济。尤其考虑到发展中国家当时软件许可制度尚未完善——即便政府机构也常毫不犹豫地使用盗版软件。
这是亲身经历吗？
发达国家向发展中国家“传授”的翻新硬件数量不容小觑。安装时已服役五年以上且退出市场的PC和服务器比比皆是。
这类机构通常配备专用定制设备。比如医院里运行Windows XP的USG机器。通常不会触碰它们，只会进行隔离处理。更别提升级到最新操作系统版本了。
这些架构当年属于高端机器，大学和政府机构确实是主要采购方，但它们很可能早已迁移到通用硬件平台；如果迁移到PC兼容架构对它们不可行，那么在设备生命周期结束后继续运行这些机器同样不可行。
(在我发展中国家的二流大学里，2000年代末太阳工作站已多年未开机，而1980年代购置的微型计算机早已沦为校内摆设)
编辑补充：大型企业拥有IBM或HP为其大型机提供的支持计划，与Debian毫无关联。
这并非复古计算。新型32位x86处理器至今仍在生产、销售和使用。
参见(相对较新的)制造商列表：
https://en.wikipedia.org/wiki/List_of_x86_manufacturers
向下滚动可查看其他类别的x86芯片制造商。这些芯片用途广泛。或许再过30年它们会主要成为爱好者玩物，但我们离那个时代还很遥远。
其中哪些不支持MMX/SSE？Debian默认禁用所有未随奔腾Pro发布的x86指令集扩展
此说法有误，Trixie 32位版本需奔腾4处理器支持
这不正是树莓派之类设备诞生的初衷吗？
若我是黑客，那些未内置硬件后门的旧式计算设备——尤其是支持运行现代软件的IntelME/AMD PSP前代硬件——其价值远胜黄金。
> 针对奔腾Pro(1995年推出的处理器！)
顺便一提，今天是奔腾Pro问世30周年纪念日。
>复古计算爱好者不需要运行当代操作系统的能力
为什么不行？出于安全性和功能考虑，我仍希望在老机器上运行现代软件
哇，这和我发布x86/x64(Windows)版本的目标平台完全一致，但连我都觉得Debian支持奔腾Pro有点过头了。
我们讨论的其实是alpha、hppa、m68k和sh4架构
首先需要说明的是，32位CPU(包括x86架构)并不属于复古计算范畴。时至今日，它们依然承担着各类重要计算系统的运行任务，且仍在持续生产(据我所知，英特尔和AMD仍在生产)。当然，其应用场景已大幅受限，更非主流选择，但确实存在。这既非爱好者领域，也非“复古”体验的载体。
但你完全忽略了功能受限的硬件，比如嵌入式系统和微控制器。这包括意法半导体、易普思、微芯科技等厂商的新产品(甚至还有复刻版“老古董”，比如兼容1970年代Zilog公司8位Z80处理器的eZ80——至今仍在消费级产品中应用)。这些大型硬件性能相当强劲，若其中部分采用基于Debian的操作系统发行版，我也不会感到意外。
32位架构或许如此，但i686绝对是。最后一批不含MMX技术的纯i686芯片大约在1998-1999年间停产。
> 这首先涉及Rust编译器及标准库，以及红杉生态系统。
所谓红杉生态，是否指用https://sequoia-pgp.org/取代GnuPG进行签名验证？
我真心希望他们别因为某个项目用“内存安全”的Rust语言编写，就贸然用这种新奇项目取代经过审计和实战检验的GnuPG组件。
红杉PGP项目至今已有8年历史，其1.0版本发布于五年前。
反观GnuPG，其代码成熟度广受认可。但这套C语言代码库几乎没有测试，没有持续集成管道(！！)，架构本质上是带副作用的状态机，还包含200多个标志位。据我观察，只有没接触过这套代码库的人才会对其赞不绝口。
坦白说，GnuPG更应因代码不成熟而遭人诟病。你甚至无需阅读代码库，只需尝试在脚本中使用它：
验证失败时它返回0，通过时返回1，而你必须忽略这些结果，转而解析状态文件描述符的输出才能得知真实状态。
它虽提供强制算法约束的选项，但这些约束仅在特定模式下生效，在其他模式中会被静默忽略。
GnuPG曾保护过斯诺登，他也对其评价颇高。
红杉PGP是否具备同等资质？其资金来源是什么？
我们在上一版Debian发行版中已用红杉PGP替换了GnuPG。
GnuPG何时接受过审计？由谁执行？
还是说Rust刚完成A轮融资？
GnuPG还剩哪些应用场景是专业工具无法替代的？
>对整个项目而言，关键在于能够向前发展并依托现代工具技术，而非因将现代软件硬塞进复古计算设备而受制。
深表赞同——这段关于现代软件现状的论述精准揭示了C语言作为Linux等系统核心架构的本质
为何这类议题常演变为个人立场与意识形态之争？
博主Gwern曾撰文探讨此问题：https://gwern.net/holy-war
后续回应堪称经典：
参考：https://lists.debian.org/debian-devel/2025/10/msg00286.html
绝对是场合中最成熟的那个。
听起来还是老样子。
邮件列表相关讨论：https://lists.debian.org/debian-devel/2025/10/msg00288.html :
[ Rust编译器手册 > 平台支持：https://doc.rust-lang.org/beta/rustc/platform-support.html ]
[ Rust官方文档 > 目标层级策略：https://doc.rust-lang.org/beta/rustc/target-tier-policy.html… ]
– 2.5pro: “Rust编译器目标移植计划” https://gemini.google.com/share/b36065507d9d :
[ rustc_codegen_gcc, 每个目标平台的 libcore 原子操作(m68k 不支持 64 位原子操作，需对 libgcc 辅助函数进行补丁修复)，… libc、liballoc和libstd(修复std::thread、std::fs、std::net、std::sync)，随后编译测试将发现数千个缺陷]
那么，在这些实际但最初模拟的指令集架构上，持续集成构建耗时如何？
“谷歌借助生成式AI将所有内部工作负载迁移至ARM架构”(2025年)https://news.ycombinator.com/item?id=45691519
“基于AI的RISC-V软件移植技术”(2025年)https://news.ycombinator.com/item?id=45315314
“模糊测试在程序移植中的非理性有效性” (2025) https://news.ycombinator.com/item?id=44311241 :
> 采用大型语言模型编写模糊测试用例，并按拓扑顺序构建移植方案的策略，在自动化C语言向Rust语言的移植过程中表现出显著成效。
我认为这很糟糕：即便是基础系统工具，也会依赖于尚未标准化且仍在演变的软件生态系统(或其部分组件)，而IIANM本身还存在更多依赖关系。我担心这可能危及平台兼容性。
即便为基础系统工具添加C++依赖都令人担忧，更何况Rust这类语言。
诚然，我并非发行版管理或引导程序等领域的专家，或许反应过度了，但此刻确实感到恐惧、不确定与疑虑交织。:-(
> 对于极其基础的系统工具，依赖关系将建立在尚未标准化、仍在“动态演变”的软件生态(或其部分)之上。
这始终是行业常态。gcc的核心工具就大量使用了非语言标准的扩展功能；Perl从未制定标准却被广泛应用。
若设计操作系统发行版，基础系统应严格遵循语言标准编写，避免依赖不稳定的扩展(并非指GCC C扩展不稳定，我推测自90年代起这些扩展大多/全部已趋于稳定)，并最大限度减少对附加工具的依赖。
例如据我理解，可通过C编译器和GNU Make构建Perl解释器。若无法实现——GCC本身具备自举能力，详见此处x86/x86_64构建流程：
https://stackoverflow.com/a/65708958/1593077
在其他平台上，你也能通过自举链的任意环节进入该流程。之后便能轻松构建Perl，详见：
https://codereflections.com/2023/12/24/bootstrapping-perl-wi…
感觉你可能混淆了本帖讨论的核心问题：apt中使用Rust属于发行版构建后期阶段(远晚于初始化阶段)，而你在帖中提及的初始化讨论更相关的是Linux内核等场景。
由于apt处于流程后期，这些初始化讨论其实关联性不大。我的观点是：在操作系统相同层级中，存在大量未满足相同标准的组件，包括Perl。
你引用的GCC构建流程包含13个步骤。其中许多工具是在发行版需要GCC之后才开发的。类似流程同样能构建Rust编译器。
需注意APT采用的是GNU版本的C++，特别是C++17(即将升级至C++23)。它始终利用最新C++特性，同时在代码中保留了针对C++标准化前编译器缺乏命名空间的变通方案…
在APT出现前，dpkg的主要用户界面是dselect，该工具采用C++编写
但这恰恰印证了我的观点？Debian是从高要求语言编写的工具转向了低要求语言编写的工具。
Rust代表着当下与未来，成为Linux发行版的关键要求合乎逻辑，但此处的措辞实在令人难以信服……最后一句显得毫无必要地充满对抗性。
我怀疑如果这封邮件列表帖子引起足够关注，最后一句将成为令人深悔的根源。
若真如此，这恰恰印证了他们的立场，完全是咎由自取。
我认为描述很准确。他显然预见到那些总想搅局的人会跳出来质疑：“那我怎么在PDP-11上运行Debian？”
没错。我确实怀念当年在全新PC上安装Linux的日子——那台机器的总内存还不及我今天电脑的缓存容量。但我们必须清醒认识到，对需要持续维护的软件而言，什么才是合理之举。我对蒸汽火车也怀有特殊情感，但到了2025年，用燃煤驱动火车显然已不合时宜。
与其执着于将Debian硬塞进本世纪初就已过时的硬件，同时还鼓吹它能胜任全新笔记本的任务，不如打造一款怀旧版Linux发行版——或许采用刻意精简或复古内核，搭配精选软件——这才是更明智的选择。
> 我对蒸汽火车也有感情，但在2025年用燃煤驱动火车显然不合时宜。
已解决问题：
美国专利申请号 3127321
专利日期 1964年3月31日
铁路车辆用核反应堆
极具《辐射》风格
但这封邮件传递的不仅是“我们将强制要求使用Rust语言，以下是时间表(部分功能可能失效)”，更暗含“我清楚哪些功能会崩溃，修复是你们的问题”(通过抄送对象传递)，结尾更采用被动攻击式措辞(“感谢您的理解”本质上是委婉表达“去你妈的”)。这种态度会激怒人们，导致他们更可能设置障碍，而非配合要求或另寻合作途径达成理想结果。
或者那些烦人的纠缠：“那如果我没有过去五年生产的X86_64处理器怎么办？”——显然我们的回应应该是：“换硬件啊哈哈，闭源不修复”
你的意思是Rust无法在2020年生产的计算机上运行？
不是，但即便真不能运行，我也不确定这会被视为问题。
哦，这听起来像是个人认知不足的问题。不过你来对地方求知了！
欢迎指教。目前我所见资料均未表明存在相反情况。
那发帖前多花点时间查证啊！
我才不会在愚人行径上浪费精力。目前两方主张都毫无依据可言。
这显然更像是语言爱好者的条件反射式反应——“实际上你绝对肯定错了，不过嘛…别问我为什么，就是错”——而非正当论点。
那就继续无知吧，继续发表蠢论还指望别人纠正你哈哈
不，支持五年前的主流硬件完全合理。但支持二十年前连当年都鲜有人用的老硬件就不合理了。
确实。已确认四个可能受影响的目标架构：
alpha、hppa、m68k 和 sh4
公平地说，摩托罗拉68xxx系列处理器当年确实有大量用户，只是那已是四十多年前的事了——比如康懋达Amiga电脑。SH4架构最广为人知的应用是世嘉Dreamcast游戏机，那还是世嘉生产游戏主机的年代。
Alpha和PA RISC虽出现在 相对 较近且更主流的硬件中，但数量极少。所谓 相对 是指本世纪初，这些绝非五年前的热销产品，当时它们只是小众市场中的利基产品——实际上已被微软所吞噬。
顺便提一句，Alpha和PA RISC正是安腾处理器的前身——若想用通俗方式感受时光流逝，这便是最佳例证。
Linux是否已停止支持老旧x86处理器？
是的，在…2012年末https://lkml.org/lkml/2012/12/12/292
据我所知Rust也没支持。
Rust对开发者而言是绝佳语言。他们热爱它，更欣赏其开发者至上的设计理念。
但对Debian终端用户来说，编译Rust项目简直是噩梦。编译器(rustc)每三个月就会进行破坏性变更——这绝非玩笑或夸大其词。在任何重要场景中使用这种快速迭代的语言都极其不妥——因为像Debian这类非滚动发行版的用户，根本无法编译为其不断更新的尖端版本编写的软件。
这是以牺牲用户体验为代价换取开发者便利的举措，完全符合现代软件的常态。
Rust具备稳定性保障。只要不更新二进制文件/库的版本，新编译器就能为该版本编译，甚至可跨版本互连——因此我实在无法理解这种论调。C++模块曾提出类似方案但未获通过。此举还能解决困扰整个语言的诸多可怕向后兼容问题。
Debian仍遵循其政策，这意味着您的使用场景不应受此影响。
rustc版本将在每次发布时固定以确保兼容性，所有Rust依赖项都必须移植到APT包管理中。
在Debian环境中，Rust版本频繁更新和“cargo地狱”带来的负担都由Debian包维护者承担。
Debian用户何时需要自行编译APT了？
> 他们每三个月就在编译器(rustc)上进行破坏性变更。这绝非玩笑或夸大其词。
事实上这是严重夸大。rustc的破坏性变更极其罕见。
我不认同这种观点。
首先，Debian并非需要用户自行编译软件的发行版。软件包已包含二进制文件，编译工作早已完成。Rust的不稳定性根本不会影响用户。
其次，作为开发者，我从未接触过比Rust更令人不快的语言。当年它的借用检查器简直糟糕透顶。Rust 并非以开发者体验为导向——Ruby 才是——但其内存安全性使其在特定场景下具有实用价值。但可以肯定的是，许多开发者会像躲避瘟疫般避开它——再加上破坏性变更和漫长的编译时间，这或许正是此类强制举措引发争议的原因。
> Rust 的不稳定性不会对用户造成任何影响。
当然会。假设某个基于Rust的软件包存在安全漏洞。上游已修复该漏洞，但修复方案依赖于Rust语言的新特性，而Debian冻结版本尚未包含该特性。
那么负责的Debian维护者会回溯移植该修复方案，就像他们几十年来在其他语言中做的那样。实际上这不会影响用户。最多给维护者和开发者添麻烦，这或许够糟糕，但绝非用户问题。
rustc稳定版确在持续更新。但Debian的每个发行版必然针对特定工具链版本，问题何在？
没错，让我们引入对一种没有规范、仅有一个编译器且支持架构寥寥无几的语言的硬性依赖吧。这才是真正的进步。
Ferrous Systems已将其语言规范(“Ferrocene”)捐赠给Rust基金会[0]，基金会正在推进整合工作，但显然这需要时间。
0: https://rustfoundation.org/media/ferrous-systems-donates-fer…
他们的规范只是描述了编译器决定实现的内容，并非权威标准。
你以为C语言是如何被规范化的？
难道是先在抽象机器中凭空构造再后续实现？不，它是以当时可用的实现版本为基础的。
更何况像Python这样的语言根本没有规范，却存在多种实现。
这恰恰是C++规范的做法。所有未定义行为和实现定义内容的存在，正是因为90年代编译器对
sizeof(int)的大小存在分歧。我认为批评规范源于实现并不公平。这恰恰证明了规范如何在实践中落地。
那又怎样？你以为规范会是什么？完全无视现有编译器的抽象描述？
我认为这个论点站不住脚，毕竟存在许多没有正式规范却大获成功的语言，Python就是典型例子。
(况且架构数量并非关键因素。质量才是核心考量，Rust选择保守地稳定在经过可靠测试的LLVM后端子集上，在我看来非常合理。)
语言规范与多个可行编译器如何帮助C开发者编写安全关键代码？
考虑到验证工具和统计分析工具的数量，且C是唯一拥有形式化验证编译器的主流语言，我认为效果相当不错。
坦白说，我甚至不反对Rust。它有很酷的想法。但我认为它应该更注重可移植性和规范定义，而且应该更早做到这一点。我强烈反对某些核心团队成员认为规范毫无意义的观点。
C语言显然始终是apt这类工具的争议性选择，但Rust在我看来更糟。Apt完全无需用低级语言编写。至少C的选型还能辩称兼容性优势，而Rust的优势实在难以觅得。
但这些措施终究没能阻止Heartbleed漏洞及其他众多CVE漏洞的出现，不是吗？
Java难道没有正式验证过的编译器吗？
Perl自古以来就是基础系统的硬性依赖项，它既没有规范，也仅有一个解释器。
要在新平台上运行Perl或Python，唯一需要满足的规范就是C语言规范。只要编译器符合该规范，就能将解释器移植并编译到新平台。
大量C程序还(无意间)依赖于规范漏洞，即未定义行为。这使得它们完全受制于编译器的一致性。
难道因为市面上还有大量运行Debian的PIC、MIP和PS/2系统？
战争已结束。ARM和x86赢了。
RISC-V正稳步崛起，有望双双挑战这两大阵营，且(最终)将全面支持Rust语言。
若真能实现我自当欣喜，但对于RISC-V这类新架构，我始终秉持“眼见为实”的态度。
关于架构支持的抱怨尚有道理(尽管：全球绝大多数系统运行在少数几种架构上)。其余抱怨纯属无稽之谈，反复提及这些论点只会暴露恶意。
能否请您理性阐述实质观点，而非采用人身攻击的论战风格？我们在此追求的是建设性讨论而非对立：https://news.ycombinator.com/newsguidelines.html。
(本子帖已从https://news.ycombinator.com/item?id=45782109分离。)
请查阅支持架构列表https://wiki.debian.org/SupportedArchitectures，其范围相当有限。官方支持仅涵盖5种架构。因此对于非主流需求，Debian从来就不是首选方案。
gccrs存在吗？
该用户以StopDisinfo名义故意传播虚假信息已被标记。此用户清楚Rust语言规范https://github.com/rust-lang/fls的存在，且曾对此发表评论： https://news.ycombinator.com/item?id=44927141(若非其宣扬谬论时使用的这个相当醒目的名称，我可能根本不会记得这套规范)。
Rust还拥有多个编译器(rustc、mrustc和gccrs)，但目前仅有一个具备生产环境部署能力。
请勿通过回复助长恶意评论；应直接举报。若已举报，请勿在评论区标注举报行为。
https://news.ycombinator.com/newsguidelines.html
你链接的Rust规范纯属形式主义，仅为满足认证流程要求。据我所知，实际上无人以此规范实现语言。
虽然存在其他Rust规范化工作(如《不安全代码指南工作组》)，但尚未形成覆盖全语言的正式规范。坦白说，现阶段这可能根本无法实现——Rust存在多层实现定义的隐性复杂性。
“存在标准但仅具表演性”与核心论点不同。
即便接受这种说法，它似乎也不构成有效的比较依据：任何编写过非简单量级C或C++代码的人都曾遭遇编译器定义的行为或语言扩展。这些现象表明C和C++标准同样具有“表演性”特征，但反复宣扬标准化的优越性与承认这一事实显然存在矛盾。
C标准的初衷是解决日益分化的C语言实现所引发的问题。他们研究了跨系统的现有行为，提出了新的语言构造，总体上取得了成功(看看90年代C语言在众多不同系统和架构上的普及程度)。
标准及其后续版本中实际采用的非正式语义采用公理化(而非操作性或指称性)风格编写，因而存在公理化语义的典型缺陷：遗漏一条规则的解读，可能彻底颠覆其他规则的理解。标准中存在若干已知定义不明确的领域，其中最严重的问题可能是类型化内存模型的推论。此后虽出现了C语言的正式语义化定义，但其普遍不如标准中的非正式版本通用，且附加了某些额外假设。
C++曾试图遵循相同模式，但其复杂度远超C语言数个数量级，因此其标准规范程度总体逊于C++标准(例如至今仍未提供C++所有未定义行为的规范性清单)。为C++编写正式规范在实践中几乎不可能实现。尽管如此，低级编程语言的内存模型研究几乎都源于C++(随后移植回C和Rust)。
内存 排序 模型确是为C++开发，后被C和Rust采用。但C++缺乏指针溯源模型——在此语境下，该模型的重要性几乎不相上下。事实证明，多进程环境下我们真正关心的内存模型问题之一是链表黑客技术，而这类技术唯有在存在来源规则时才有效——可惜C++在来源规则应有的位置上只留了个 耸肩 表情，实在不够理想。C语言虽有ISO文档(尽管尚未纳入ISO C标准，目前仅是补充文件)，但Rust已明确规定了来源规则。
此外，C++的排序模型存在缺陷：它不仅提供了实际使用的排序规则，还包含一种无人知晓如何实现的排序方式，本质上只是空想。多年来C++标准将该排序标记为“暂时不推荐”，专家们试图修正其定义，而C++26计划直接将其废弃。Rust并未复制这个缺陷。
他们确实存在一份文档，有时被称为“规范”，但其README明确声明并非正式规范：
需要明确的是，我的论点并不取决于 FLS 是否属于 Rust 的规范性说明。核心观点在于：被“规范化”既非语言成熟度的必要条件，也非其质量的充分条件。
[已删除]
傲慢体现在何处？在我看来这不过是平实无华的声明。
[删除内容]
Debian和Canonical有关联吗？那不是Ubuntu吗？
Ubuntu是基于Debian构建的
[删除内容]
能否提供你所指内容的链接？据我理解，本公告涉及Debian工具链，而你提及的是Linux内核开发讨论
若承诺第一件事的人并非执行第二件事的人呢？
我不理解Rust的必要性，毕竟需要高速二进制文件时，我完全能愉快地将Common Lisp编译为机器码。
但使用这种语言的人们拥有惊人的才能——只需寥寥数语就能让犹豫者彻底反感。
他们让我想起基督教传教士，试图将野蛮人从献祭人血的蛮荒宗教，转化为烧死异端的文明宗教。
许多程序员对Lisp用户也有同感。最好抛开对这个社群的直觉偏见，主要思考该技术在技术层面和组织层面的优缺点。
没错，但我们没在推动所有项目都采用C/Lisp双语代码库。
Rust用户不知为何却在这么做。
Lisp最经典的宣言之一就是宣称其他语言皆逊于Lisp，所以我觉得这算不上好例子。
你是说“所有语言终将收敛于Lisp”那句？这倒是个事实 🙂
没错，盲人终将跌跌撞撞下山。但我们任其按自己的节奏前行。
虽非Rust或系统语言专家，但这绝非“莫名其妙”。原因其实极其明确——旨在消除Linux历史上最大规模的安全隐患源头。
但它真是最大隐患吗？根据https://owasp.org/www-project-top-ten/，它应归类于第6或第8大隐患。虽然人总能边走路边嚼口香糖(重写系统软件的人通常不会是需要设计更完善访问控制系统的人)，但替换稳定软件并非毫无风险(例如https://lwn.net/Articles/1043103/ (https://lwn.net/Articles/1043103/)，这正是Rust引发的#6类问题)。若缺乏开发者背景信息，你会信任用Rust重写的OpenSSH吗？
Owasp仅关注Web安全领域。该领域整体偏向于PHP/Ruby/JS/Python/Beam等语言，这些语言在原生模块之外基本不存在上述问题。
https://www.cvedetails.com/vulnerabilities-by-types.php 的说明更为清晰。攻击类型依次为跨站脚本攻击、SQL注入和内存漏洞。前两类无法强制修复——攻击者总能绕过可见标注实施恶意操作。即便如此，Rust这类丰富类型系统仍能简化安全接口的构建。但Rust真正解决的是下一类问题：可验证安全性的漏洞，或需显式声明“unsafe”的漏洞。
但有多少安全漏洞会获得CVE编号(或由CVE引发)？考虑到用户及其数据通过网络交互的频率远超其他平台，减少服务漏洞比减少CVE数量更能改善用户体验(MongoDB默认不设置用户名/密码访问是否存在CVE？)。
至于防范跨站脚本攻击和SQL注入，这正是优质Web框架的职责所在。若框架鼓励编写未经转义的原始SQL语句，或未提供合理的内容策略默认设置，那么无论采用何种语言，问题都将持续存在(或许我们该将这类框架称为“不安全”框架，这样才能推动其修复)。
数据统计[1][2][3][4]始终显示近80%的安全漏洞源于内存安全缺陷。我认为这是最大威胁。尤其微软文档明确指出该比例自2006年以来始终稳定，表明再多的外部工具和培训都无法解决根本问题。[1] https://langui.sh/2019/07/23/apple-memory-safety/ (尽管苹果通过采用新语言和优秀的CPU扩展解决了该问题)[2] https://www.microsoft.com/en-us/msrc/blog/2019/07/we-need-a-… [3] https://security.googleblog.com/2019/05/queue-hardening-enha… [4] https://x.com/LazyFishBarrel/status/1129000965741404160
具体是哪个代码？什么才算安全漏洞(比如Play商店的设计缺陷——搜索应用时首条结果并非目标应用也算吗)？和其他人一样，我也想要安全的浏览器，但我的安全浏览器无法阻止我的邮箱(或密码)出现在https://haveibeenpwned.com/上。我喜欢Rust语言，也想用它写更多代码，但如果我要把OpenSSH移植到Rust上，我敢保证我的Rust代码会比OpenSSH本身包含更多CVE漏洞。
我认为在apt中使用Rust这个具体案例里，这 很可能 是好事(尽管我希望采用现有经过充分测试的Rust库，而非因“非我发明症”引入新漏洞)，但迄今Ubuntu的Rust化进程并不顺利，因此我对诸如通过Rust改进Firefox这类变更持更谨慎态度。
我不认同openssh的观点，但确实无需将所有项目迁移至Rust，且迁移过程往往波折不断。我在Arch系统上使用sudo-rs已逾一年，至今未遇任何问题。
> 原因其实极其明确
无法保证Rust生态中不会滋生其他漏洞。除了一句空洞的“相信我们”(参见满是CVE漏洞的Firefox，尽管它“基于Rust”)，Rust程序尚无公开的质量代码检测机制。再加上Cargo生态中任何恶意行为者都能注入恶意代码的隐患，这无疑是重大警示信号。
据我所知，Linux直接使用rustc编译器，并未依赖Cargo。
附带一提，朝日Linux开发者曾表示Rust极大简化了苹果M1/M2系列驱动的编写(相较于C语言或许更易)，可见即便脱离Cargo生态，该语言仍具优势。
此外Rust仅能减少特定类型漏洞，某些缺陷无法避免。数年前(据信是微软)指出70%的漏洞与内存相关[0]，这意味着Rust本可规避其中大部分问题。
或许Rust并非最佳解，但目前它是最经实践验证的解决方案。谁知道未来Zig或其他语言是否会取代C和Rust呢？
[0] https://www.zdnet.com/article/i-ditched-linux-for-windows-11…
我可能理解有误，但…你的意思是Rust程序仍可能存在漏洞？这不就和其他语言程序一样吗？只不过Rust能避免导致多数CVE漏洞的灾难性常见缺陷？
若理解正确，那么“它仍不完美”如何成为论据？
同意对Cargo的质疑。
如果不需要完美，我们大可继续使用这个20多年历史的成熟代码库，没必要迁移到其他语言。毕竟 “解析.deb、.ar、.tar的代码” 已经完成，任何内存漏洞也早该修复了。
请随意用Rust开发长青项目，但成熟的测试系统就别碰了。
我不明白你如何从 “更好但不完美胜过更差” 得出这个结论。
明白了？所以你的立场是Debian只该收录有投票权的古老软件？
还是说Debian永远不该依赖2015年后编写的任何软件？
Firefox代码构成：29% Javascript、28% C++、22% HTML、10% C、3% Python、2.6% Kotlin、5% 其他
> 无法保证Rust生态系统中不会滋生其他漏洞。
不过得益于先进的类型系统(例如允许抽象层设计者构建更防呆的API)，其风险确实低于C语言。
> 任何恶意行为者都能注入恶意代码的现状堪称重大警讯。
对此我深表怀疑…
Rust代码能确保避免多种缺陷的发生，这本身就是重大进步。
难道能保证C生态中“其他漏洞”不会滋生吗？
Firefox根本没用100%的Rust实现。
这完全是无知之言。
众多重大项目已无可辩驳地证明：迁移至内存安全的语言必然带来更安全的软件。
我对Go社区也有类似感受。总体而言我喜欢Go，但某些方面实在糟糕。这个“Go社区”诡异地像个邪教组织，批评语言本身往往招致非议。因此我极少与他们互动，只专注于自己的工作。
> 我不理解Rust的必要性，毕竟需要高速二进制文件时，我完全能愉快地将Common Lisp编译为机器码。
这与Rust的价值无关——Common Lisp早已式微无人问津，而Rust正蓬勃发展并创造价值
若价值在于网络剧场，那它确实做到了。
Rust并未“创造价值”，人们只是被洗脑了。Common Lisp有其特定领域，至今仍表现出色：它从来就不是成功的通用语言。
> Rust并未“创造价值”
请提供依据。
或者，任何缺乏证据的论断都可以用ripgrep来反驳。
哇哦，居然要替换我现有的工具。速度虽略快些，但我压根不在乎运行速度。谁在乎呢？
Lisp既无静态类型又用垃圾回收，怎么可能快？
作为GC语言，Common Lisp慢如蜜糖。但在慢如蜜糖的语言领域中，它的性能已相当可接受。我猜这部分归功于它来自多元宇宙之外的异星科技，部分也源于70、80年代那些在所谓人工智能寒冬中失传的精妙技术。
此外，通过声明机制，程序员可告知Lisp编译器(例如)将变量栈分配以提升性能。Lisp代码本质即数据的特性同样利于性能优化——这意味着宏编写相对容易，部分计算可在编译时完成。规范中还包含多种实用工具，如time和trace，可用于分析程序执行过程以辅助优化。
最新消息：自80年代以来，Lisp编译器已大幅改进。通常情况下，未优化的标准Lisp性能可与Java比肩，而采用优质编译器进行优化的Lisp甚至能媲美C++。SBCL作为卓越的编译器，其垃圾回收技术已取得长足进步。
SBCL固然出色，但GCC和LLVM获得的资源投入，加上CPU厂商为提升C语言及相关过程式语言性能而设计的架构特性，使得Lisp面临艰巨挑战。我认为通过合理运用sb-simd和区域分配等技术，性能可接近C语言水平。但经过调优的C/C++/Rust能达到惊人速度(当然Fortran更强，但它无可比拟，暂且不提)。
“既然能直接链接到Node，何必用C？”
[已删除]
目前这个帖子里：0人推销Rust，几人推销Common Lisp，还有一群人抱怨Rust推销者(包括你)。
耐人寻味吧？
> 基督教传教士试图感化野蛮人
快进五个世纪，事实证明他们相当成功——如今天主教在南美洲和中非地区最为活跃，远超欧洲。
是的，通过在那些地方大开杀戒。
绝大多数并非来自宗教人士。
杀戮减少，鸡奸行为大幅增加：https://www.abc.net.au/news/2025-01-29/former-bishop-broome-…
基督教兄弟会的传教站遍布未开发地区，实为人间地狱。
* https://www.theguardian.com/uk-news/2017/mar/02/child-migran…
* https://www.childabuseroyalcommission.gov.au/case-studies/ca…
喜欢朱利安的邮件风格。礼貌得体，却又坚定果决。
Rust传教士实在令人厌烦。无论你吸多少Rust迷幻药，它都解决不了技术债务问题。只要规范使用C语言，配合Valgrind这类现代工具，就能获得安全代码——无需像被切除脑叶般为每个借用检查器争论不休，哪怕面对显而易见的简单代码。
作为Valgrind开发者，若它能保证代码安全自然再好不过。可惜事实并非如此。首先它无法检测所有错误(实际上没有任何工具能做到)，其次测试覆盖率不可能完美无缺。
妄想仅凭开发者“技术能力”就能弥补C语言诸多缺陷，这种过度自信并非保障安全性的解决方案。
我认为反对将Rust纳入用户空间系统的观点，同样应反对Perl、Python、Ruby等语言。
真正可怕的是那种必须安装多种大型语言模型才能启动的发行版。
呜呼！
几个月前他们不是刚把Rust软件称为“无法打包”吗？依稀记得当时讨论的是bcachefs-tools。
Debian 包装 rustc 和基于 Rust 的程序已有近十年历史。
最近我尝试构建 Debian 软件包。虽然没有遇到崩溃，但完全搞不懂操作流程——尤其是那份矛盾混乱到离谱的文档。幸好我主要在 Artix 上用 makepkg，操作简单得多。
实在难以相信这真是为了提升质量，明明还有其他更重要的大目标可做。
你确定没把文档和网上那些人的随意评论混为一谈？因为这个话题上充斥着大量盲目模仿的现象。
当官方文档毫无用处时，人们只能寻找其他可能的帮助资源，而其中大部分早已过时。
官方文档哪里出了问题？
几个月前我做过类似操作，具体细节已记不清，但当时想为特定版本的Ubuntu(或Debian)生成二进制包并放入PPA，方便用户使用我的代码。当时觉得规则文件可以随意编写，不必实现那些无关紧要或难以理解用途的目标。于是用了脚本。错误——现在看来makefile才是主流方案。
我苦恼于GIT仓库的目录布局设计。更复杂的是，我需要直接从GIT仓库构建(而非tar包)，这给开发者提供了不稳定环境而非可发布的稳定版本。
更令人困惑的是……构建的二进制插件该存放于包安装目标的哪个位置？我无意回溯细节核查，但依稀记得文档对此含糊其辞，仿佛可随意放置，而网络上不同用户文档的示例也各不相同。
我勉强在本地机器上构建成功，但这远远不够——PPA必须能自动构建，之后还得上传等待，祈祷日志能清晰说明问题所在。
我尝试研究其他软件包——当时正在为GNU make构建插件——但发现它们采用tar包构建方式(依稀记得)，对我这种仅包含几个.so文件的简单软件包而言过于复杂。
耗费数周尝试所有可能方案才走到这一步，如今我已精疲力竭。我并非编程新手——只是打包新手——因此我认为用户体验方面大有改进空间。别误会，我并非针对.deb格式。RPM同样是个极其糟糕的打包系统，任何细微失误都可能导致漫长重建过程。
它们显然很复杂，因为试图提供太多功能。例如Artix不使用selinux，这直接避免了一项麻烦，但随之产生了其他后果。
我认为核心文档根本无法消除这些困惑。它们似乎只是面向已有经验者的参考资料，以及针对特定简单场景的教程——而我的情况并不属于此类。若文档能满足需求，人们根本无需费心编写自己的教程。
这似乎是对Debian构建包方式的批评。部分观点或许有理，但我未能看出文档矛盾之处。
软件包构建方法历来存在演变，文档或许需要说明当前与历史差异，以便开发者警惕过时方案。同时文档也需足够全面，避免开发者去寻找可能已失效的他人解答。
回归我的核心观点——我不认为Rust能解决这个问题。