编程与软件工程raphlinus.github.io
关于 Rust 臃肿的思考
Thoughts on Rust bloat
2019 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2019 年的文章讨论 Rust 项目中的“臃肿”来源：依赖树、泛型单态化、序列化等如何拖慢编译并增大可执行文件，同时给出减小体积和编译时间的实用取舍建议。作者在后续评论中澄清，他并非断言 Rust 本身必然臃肿，而是指出这是常见问题，Rust 仍可通过控制依赖和泛型写出很精简的程序。
为什么经久不衰：它把 Rust 生态里编译慢、二进制大、依赖多的长期痛点讲得具体，又有作者多年后的复盘和社区反例，今天读仍能帮助开发者做体积与性能取舍。
HN 评论精选
安装器体积和依赖碎片化都在恶化。
Rust 臃肿是严重问题，我认为它没有被认真对待。我六月提过平台体积问题，而且之后明显更糟：两个月里安装器从 203 MB 涨到 299 MB。更难以置信的是，Rust 也没解决包碎片化，我认为这毁了 Node 社区；热门包 cargo-edit 现在会拉入 239 个其他 crate。
svnpenn查看英文原文
Rust bloat is a serious issue that is not being taken seriously I think. I raised the issue about platform size in June: https://github.com/rust-lang/rust/issues/61978 and its actually gotten worse since then, significantly worse. In the 2 months since then the installer has increased from 203 MB to 299 MB. Also unbelieveably, Rust has failed to address package balkanization which I would say has ruined the Node community. A popular package is "cargo-edit", which currently pulls in 239 other crates: https://github.com/rust-lang/cargo/issues/2179#issuecomment-523567384
关键是 Cargo 层共享缓存/预编译，局部优化不够。
作者最困扰的似乎是依赖的编译时间。Cargo 需要更好地做共享缓存（让每个依赖在每台机器上最多编译一次），或支持预编译 crate（这样根本不用编译）。编译器速度的渐进改进或裁剪单个依赖不会带来所需的 10 倍提升。
pornel查看英文原文
It looks like the author is most bothered by compile times of dependencies. Cargo needs to do better with shared caches (so you compile each dep at most once per machine) or ability to get precompiled crates (so you don't even compile it). Incremental improvements of compiler speed or trimming of individual dependencies won't bring the 10x improvement it needs.
作者澄清原意是实用减体积建议，并指出序列化仍是主要成本。
这是一年半前写的，但我认为仍然站得住。首先，标题措辞很重要：很多人把文章解读成“Rust 有臃肿问题”，这不是我想说的。臃肿是现代世界常见问题，Rust 也不能幸免，但 Rust 给开发者很多控制，目标明确时也能产出极精简的程序（有代价）。文章本意是给减少编译时间和可执行文件体积的实用建议，发表后立即推动了 gfx-hal 的改进。序列化仍是问题：现在 Runebender 约一半编译时间和可执行体积来自字体 UFO 格式的序列化。更好的序列化方案会是个好项目，但很难。不同人对“臃肿”的期望也差异很大。
raphlinus查看英文原文
This was written a year and a half ago, but I think holds up pretty well. Some thoughts. First, one lesson is that the exact wording in headlines matters. Many people interpreted the essay to say "Rust has a bloat problem," which is not what I was trying to say. Bloat is unfortunately a super common problem in the modern world, and Rust is not immune. But Rust also gives the end developer a lot of control, and is capable of producing wicked-lean programs (at some cost) if that's the goal. The point of the essay was to give practical advice on how to reduce compile times and executable size. From that perspective, publishing the essay was a pretty big success, as it immediately provoked improvements in the gfx-hal project. Serialization continues to be a problem. Now, something like half the compile time and executable size for Runebender is serialization for the XML-based UFO file format for representing fonts. I think a better solution to serialization might make a good project for a smart, motivated person, but it's pretty far away from current academic fads, and there's also this thing that a lot of people have tried and we're still not in a great place. What about serialization makes it so intractable? Could some kind of language support make it better? Also, from followups in UI threads, the expectation for what constitutes "bloat" is very different for different people. The calculator example in Druid is now about 1.5M (release build, Windows), which I think is acceptable for most people, but I'm also aware that a simple calculator like that could be built in a couple hundred k or so without too much problem, and I'm sure much less if you start using demoscene style techniques. But I also don't want to focus on that too much - I don't want tiny calculator demos, I want rich applications that work in all languages (including input methods) and also play nicely with accessibility tools such as screen readers. That can't be, and shouldn't be, a tiny little executable.
许多体积有合理来源，不能简单视为臃肿。
文章提到了一些，但我建议人们对“可执行文件体积臃肿”的指责更谨慎。Unicode 表可以删，但那样程序就无缘无故只支持英语和类似语言；用 64 位是因为经常突破 32 位限制，但代价是大量数据从 4 字节变 8 字节；还有本地化、异步运行时等。把东西移出可执行文件只是把体积拆成几块，并不等于真的更小。现在还指望一个“严肃”程序塞进半兆，有点像白日梦。
jerf查看英文原文
The article does mention this a bit, but I would suggest to people to be a bit more careful about accusing everything of executable-size-bloat. We have the mentioned Unicode tables. Can you cut them? Sure, but now you've got a binary that only works in English and very-English like languages for no reason. We use 64-bit stuff for good reason, because we routinely blow out 32-bit limits, but that's 8 bytes for all sorts of things that used to be 4, pervasively throughout the code. We have localization support. We have some sort of async runtime or memory managing runtime or other thing like that. We have all sorts of things like this. If you sit down and take an inventory of what's going on, the minimum size for some sort of "serious" executable is still going to be quite a lot. (Could you move some of this stuff out of the executable? Yeah, but that really only addresses the immediately visible executable size and comes with tradeoffs of its own... it doesn't mean the executable is "smaller", it just means it's split into pieces.) It's a bit of a pipe dream now to expect some sort of "serious" executable (one that actually has all these concerns) to fit into half-a-megabyte anymore, just because Commodore 64 programs used to fit into a hundred kilobytes.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选