Discord 客户端弃用 Electron，全面用 Rust 与 GPUI 重写

本期 云栈社区 整理的 Rust 生态速报聚焦四件事：Discord 官宣摒弃 Electron、全面转向 GPUI，rustc 十一月编译性能月报，systemd 合并可选 Rust 支持，以及 benchfmt.rs 桥接 Go benchstat 的基准测试。

Discord 客户端改用 GPUI

Discord 联合创始人 Stanislav（@svishnevskiy）2026 年 11 月 4 日在 X 上发帖，宣布了一项重大技术转向。KeyGlove47 将截图转发到 Reddit 的 r/rust 板块，采集时获得 927 分、90 条评论。

帖子指出，Discord 自 2018 年起就开始使用 Rust，基础设施、语音技术以及现有客户端的一部分已经是 Rust 实现。下一步，他们计划把整个客户端换成 Rust：移除 Electron，也移除 React Native。移动端保留原生 UI，桌面端和移动端通过 Rust 共享应用代码。帖子预计很快进入用户测试阶段。在 UI 框架的选择上，帖子点名的方案是 GPUI，并明确表示 Tauri 不在考虑范围内。

截图中的进程列表出现了 "Discord Phoenix" 一项，内存占用约 290.2 MB。

社区讨论方面，moon-w0man 的评论获得 68 分。他指出，GPUI 在操作系统集成和无障碍功能上仍有不少缺口，而 gpui-ce 和 Zed 正在分道扬镳。crispy-addison 的评论获得 3 分，补充说他们团队曾为 gpui-ce 提供过无障碍补丁，体验已接近 Electron 的水平。

原文链接：https://x.com/svishnevskiy/status/2118081920194203799

rustc 十一月的编译耗时

这是 Nicholas Nethercote 发布的编译器性能月记，记录他在 Hexcat 工作的第一个月。文章于 2026 年 11 月 4 日发布到 r/rust，采集时获得 228 分、17 条评论。上一期月报的日期是 2026 年 9 月 30 日。

Span 是 rustc 内部的核心数据结构，AST、HIR、MIR 的节点都携带一个 span。每个 span 拥有四个 32 位字段，总计 16 字节：源码位置 lo/hi、宏相关的 context，以及用于降低小改动影响的 parent。多数 span 可以压缩为三种 8 字节内联格式之一，其余则放入全局表。

• PR #163857 更换了压缩方案。增量编译中需要 intern 的 span 从旧方案的 20%–40% 降到大约 1%，非增量编译通常低于 0.1%。context 在 intern 之后也能内联存放。一批基准的指令数下降，最佳情况超过 3%，周期数下降更多。增量编译的改进更大。
• PR #163971 由 Josh Triplett 提交，顺着新表示做了几处 span 操作的微优化，最佳情况指令数下降超过 2%。
• PR #163628 在查询 parent span 的哈希表前面加了一条单条缓存。最佳情况指令数下降超过 4%，主要落在增量编译场景。
• PR #164291 尝试用 pattern type 给 Span 留 niche，使 Option<Span> 和 Span 大小一致。代码能编译通过，但由于 Option<Span> 在 rustc 中使用不多，性能没有提升。作者最终放弃了这个改动。

新 trait solver 这边有三个 PR：#163981、#164234、#165160，针对 Diesel 做了优化。新 solver 在 Check Full 上的指令数开销从旧 solver 的 1.49 倍降到 1.16 倍。typenum 和 nalgebra 也有改进。

PR #164484 由 Takayuki Maeda 提交，给元数据加了稀疏编码。指令数略有增加，周期数和墙钟时间基本持平，但元数据体积最多降低 37%，峰值内存最多降低 7%。

2026-09-28 到 2026-11-02 的墙钟时间对比中，达到相关阈值的结果有 236 项改进、4 项回退，分布在 45 个基准上。如果把低于方差阈值的结果也算进去，平均墙钟时间下降 2.85%，平均峰值内存下降 4.46%。

从 2026-01-01 算起的指令数比较共有 561 项测量：560 项改进，仅 1 项回退，改进中第二差的也有 3.10%。这个观察来自 Matyáš Racek。

原文链接：https://nnethercote.github.io/2026/11/04/how-to-speed-up-the-rust-compiler-in-november-2026.html

systemd 接受用 Rust 写程序

Amutable 发布了一篇说明，确认 systemd 已合并可选的 Rust 支持。对应 PR 为 https://github.com/systemd/systemd/pull/44324 ，由 GitHub 用户 brauner 提交，状态为 Merged。eszlari 于 2026 年 11 月 4 日将文章分享到 r/rust，采集时获得 92 分、15 条评论。

PR 明确指出：变化的是程序可以用 Rust 来写。libsystemd-shared、libsystemd 以及 NSS 和 PAM 模块继续用 C。Rust 程序和 C 程序一样，动态链接 libsystemd-shared。

一个关键约束是：Rust 代码使用 core，不用 std，不用 alloc crate，也没有任何外部 crate。这意味着这里的 Rust 代码运行在非常底层的环境中，不依赖标准库的能力。

构建选项默认设为 auto。需要 rustc >= 1.85、bindgen >= 0.71.1——这正是 Debian 13 自带的版本。bindgen 0.72.0 会被明确拒绝，因为它生成的代码编不过。auto 模式在检测到工具链时启用；-Drust=enabled 则在找不到工具链时直接失败。此外还需要 meson 1.4.0 来接入 rust 模块的 bindgen()，在更老的 meson 上，-Drust=auto 会自动关闭。交叉编译目前还未支持。

构建流程走 meson，不走 Cargo。溢出检查在所有构建类型中打开，panic=abort。警告仅在 --werror 时视为错误。

文章将支持范围分成两类：

• 叶子组件：单个二进制，项目已经接受。
• 根组件：把 Rust 放进 libsystemd-shared.so，目前不接受。文章解释，这需要等待 Rust 有一等的共享库支持。systemd 现在有 180 个以上的小二进制，静态链接会导致共享库和大量二进制携带重复的 Rust 代码。

文章还列了几条约束：C 和 Rust 二进制在解析选项、显示帮助、输出错误上保持同一套行为；路径查找继续使用 systemd 自己的 chase*()，基于文件描述符实现；分配失败按可失败处理，项目提供自己的分配器 crate；已有 C 代码不会为了换语言而重写；Rust 仍然是可选项，没有 Rust 的 systemd 继续可用。

文章末尾提到，Rust 1.100 中有一处改动会破坏刚合并的 Rust 支持，rust-lang/rust#164855 很快将其回退了。

原文链接：https://amutable.com/blog/systemd-loves-rust

benchfmt.rs 接上 Go 的 benchstat

benchfmt.rs 是一个零依赖的 Rust 基准运行器，能够把 Criterion 的结果转成 Go benchstat 能读取的格式。仓库地址：https://github.com/bwplotka/benchfmt.rs 。kibwen 于 2026 年 11 月 4 日将文章分享到 r/rust，采集时获得 8 分、暂无评论。

它补充了 /key=value 分组、每次操作的分配字节 B/op、分配次数 allocs/op，以及 pprof 支持。仓库还附带了 Criterion 和 libtest 转换器，可以直接输出 Go 的 benchfmt 格式。

文章用两段解码代码进行对照测试：

• DecodeVarints：36 行的无符号 LEB128 解码器。样本 varints_2000.bin 有 4,798 字节、2,000 个 uint64，写入预分配切片，堆分配为 0。
• DecodeRemoteWrite2：解 Snappy 压缩的 Prometheus Remote Write 2.0 请求体。2,000 条 series 的样本未压缩时为 244.9 KiB，Snappy 压缩后为 57.0 KiB。

测试环境是一台 24 核 Intel Xeon 2.20GHz 机器，Go 1.26.8、Rust 1.99.1。每个基准跑 6 轮，每轮 2 秒，使用 -cpu 2。

结果对比如下：

• Go 的 DecodeVarints：8,514 ns/op、563.52 MB/s、0 B/op、0 allocs/op。
• Rust 在 DecodeVarints 上快 37.16%（5.36 µs 对 8.54 µs）。
• 2,000 条 series 的 Remote Write 解码中，Rust 快 17.68%。

分配计数带来另一组数据。2,000 条 series 时，Rust 的堆分配次数少 14.55%（16,490 对 Go 的 19,297），但堆字节多 30.98%（2.05 MiB 对 1.57 MiB）。200 条 series 时，Rust 的堆字节多 42.59%（271.9 KiB 对 190.7 KiB）。文章分析，Go 的 protoc-gen-go 会生成指针切片，嵌套结构体单独分配；Rust 这边 88.4% 的分配字节来自 prost 中 Vec 按 2 倍扩容的策略。

Snappy 解码部分，Go 的 x86 汇编 snappy.Decode 大约 0.12 ms/op，纯 Rust 的 snap 大约 0.18 ms/op。Remote Write 整段解码里 Go 仍然更慢。文章将差额记在 runtime.mallocgc 和 GC assist 上。

原文链接：https://www.bwplotka.dev/2026/rust-microbenchmarks-benchstat/