Rust 是否应该增容标准库？

“ Reddit 热帖近 850 赞引爆辩论：Rust “小而美”是否已成供应链毒药？

正反观点激烈碰撞。总体说来：rand、embedded-hal、基础数学，这仨轮子必须焊死在官方准标准库里，否则不敢上路。”

昨晚，熬夜阅读了 Reddit 上一个 Rust 标准库辩论帖：Unpopular opinion: Rust should have a larger standard library，该帖目前已经逼近 850 个赞，评论区吵的挺热火。

这次踩中了 Rust 生态最脆弱的神经——供应链安全。

写个随机数都要引入第三方库？

帖主灵魂吐槽：

"I can't write a simple program without pulling in a bunch of dependencies that nobody has time to audit."

用 Rust 写个最简单的 HTTP 请求，是不是先要伺候一遍 reqwest、tokio、hyper、serde_json？为了生成一个随机数，我凭什么要去 crates.io 上翻第三方包？

在 Go 里 crypto/rand 是家里人；在 Python 里 random 模块开箱即用。唯独 Rust，你得虔诚地请出 rand 大仙和他的徒子徒孙们。

供应链安全的达摩克利斯之剑

高赞评论直击要害：

"By the time you realize some obscure crate deep in your dependency tree has been compromised, your server keys are already long gone."

这不是危言耸听，最近几周朝鲜背景的 APT 组织疯狂向 crates.io 投递恶意包。大厂安全审计面对动辄几百个间接依赖，直接原地摆烂——不是不想查，是真的查不完。

Rust 的“小而美”哲学，以前是典范，现在怎么看怎么像 “官方甩锅，全员裸奔”。

反方选手：嵌入式大哥先怒了

反对扩大标准库的声音也很硬核：

“你考虑过嵌入式开发兄弟的感受吗？”如果 libstd 像 Go 那样塞满 http、json，几 KB 内存的单片机连 Hello World 都烧不进去。臃肿的标准库会直接杀死 Rust 在硬核领域的核心竞争力。

也有开发者指出：

"Nobody is forcing you to use reqwest. You choose convenience over security."

这话虽扎心，但也点出事实：Rust 社区对 “重复造轮子” 的文化容忍度极低。

能用现成高 star 库搞定，谁愿意手搓裸 Socket？

嵌入式玩家的切肤之痛

聊到这里，作为一个成天跟舵机、IMU、激光雷达打交道的，想把 Rust “塞进”嵌入式硬件，什么机器人小车、机械臂的开发者，我得说点大实话——这个问题在嵌入式领域被放大了十倍不止。

做嵌入式跟做 Web 服务完全是两个世界。Web 后端依赖多，好歹跑在 x86 服务器上，内存管够，编译慢点忍了。

但嵌入式机器人是什么场景？

第一，交叉编译地狱。

你搞个树莓派或者 Jetson 做 ROS 节点，第三方库一多，交叉编译配环境能让你怀疑人生。openssl-sys 要链接、ring 要折腾目标三元组、tokio 的 mio 还得处理不同架构的 io-uring。

好不容易在本机 cargo build --target=aarch64-unknown-linux-gnu 过了，烧到板子上直接 Segmentation fault。查半天发现是某个底层 sys crate 在 ARMv8 上有个未定义行为。

第二，实时性约束。

机器人控制闭环跑在微秒级精度上。你做伺服控制，PID 算完到 PWM 输出之间，中间件稍微抖一下，电机就过冲了。std::time::Instant 在标准库里倒是稳稳当当，但你想加点滤波算法？不好意思，得拉 nalgebra 或者自己手搓矩阵运算。

用 nalgebra？它又依赖 num-complex、approx、simba，一堆泛型和 trait 展开后编译时间爆炸，最要命的是——你根本不知道这些间接依赖里有没有偷偷分配堆内存。在硬实时线程里，一次隐蔽的 heap allocation 就是一次潜在的抖动灾难。

第三，硬件抽象层的碎片化。

玩嵌入式的兄弟最懂这个痛。你用 STM32 的 HAL 是 stm32f4xx-hal，换到 ESP32 变成 esp-idf-hal，再换到树莓派 Pico 又是 rp-pico。

每个 HAL 的 API 风格都不一样，有的用 embedded-hal trait 还算规矩，有的干脆自己另起炉灶。要是标准库能给个基本的 GPIO、I2C、SPI 抽象 trait，何至于换个 MCU 就跟学门新语言似的？

一位做无人机飞控的同行在 Hacker News 上吐槽过：

"Every time I switch flight controller hardware, I spend two weeks just rewiring the HAL glue code. This is not engineering, this is plumbing." （译：每次换飞控硬件，我得花两周时间重写 HAL 胶水代码。这不叫工程，这叫通下水道。）

折中方案：“准官方”的野望

社区提出 “准标准库”：Rust 基金会收编 rand、serde、tokio 这些事实上的基础支柱 crate。它们独立于 libstd 编译，不增加嵌入式负担，但受同等安全审查。

既保留“小核心”灵活性，又给企业用户定心丸。

个人观点：机器人（嵌入式）的轮子，得焊死在车轴上

我对这场辩论的态度非常明确：标准库可以不大，但机器人的基础轮子，必须焊死在车轴上。

什么意思？我玩把 Rust 塞进嵌入式的体验，最怕的不是标准库大，而是底盘不稳。

Web 服务崩了重启就好，机器人小车崩了是真会物理撞墙的。

所以我需要一套经过铁锈般验证的、签名可信的、行为确定的基础组件。

比如 no_std 下的数学原语。我现在做四元数姿态解算，要么手搓矩阵乘法，要么引入 micromath 或者 libm。手搓容易出 Bug，引入第三方又回到审计问题。如果 Rust 官方能维护一个 core::math 子模块，提供 sin、cos、atan2 这些在 no_std 下确定行为的基本函数，我做 IMU 融合能省多少心？

比如基础硬件抽象。embedded-hal 现在是社区维护，版本迭代靠爱发电。0.2 升 1.0 前后折腾了三年，期间各种 HAL 实现版本分裂，驱动 crate 兼容性一塌糊涂。如果这些 trait 能进入 core 或者一个官方 bless 的 rust-hardware 命名空间，整个机器人生态的地基会稳固十倍。

再比如通信协议栈。我做机器人小车离不开 CAN 总线、串口、I2C。现在 serialport 库好用是好用，但它是个人维护，作者一忙 PR 就积压。工业现场用的 SocketCAN，socketcan-rs 也是社区项目，跟内核版本强耦合，Linux 内核一升级就可能挂。

所以我的观点很粗暴：对嵌入式开发者而言，可靠性压倒一切。

我不在乎标准库编译出来是 2MB 还是 20MB——反正我交叉编译的 rootfs 动辄几百兆，不差这点。我在乎的是：三年后我重新编译这套飞控代码，它还能一丝不差地跑起来；我在乎的是每引入一个依赖，都有人为它的安全性签过字。

Go 那种大标准库模式，放 Web 后端可能是过度设计；但放在机器人这种长生命周期、高可靠性、物理安全攸关的领域，恰恰是刚需。

所以，Rust 团队，听听群众的呼声——

标准库不用学 Go 那么大，但 rand、基础数学、embedded-hal trait、CAN/串口协议栈 这几样机器人吃饭的家伙，请收编进“准标准库”。

别让嵌入式（机器人）开发者每次搭环境都像在雷区里跳踢踏舞。

底盘不稳，上层算法再牛也是空中楼阁。这个轮子，得由官方来造。

谢谢您的阅读，欢迎交流。如果您发现错别字，也请向我发信息。