webrtc 0.20.0：Rust 异步 WebRTC 正式改成运行时无关，数据通道吞吐最高超过 Pion 3 倍

webrtc-rs 发布 v0.20.0，这是新架构的第一个正式版，也意味着过去强绑定 Tokio 的 v0.17.x 线进入仅修 bug 维护状态。这个版本最关键的变化不是“又发了一个版本号”，而是把运行时抽象真正做成了可扩展接口：计时器、I/O、spawn 这类会碰 reactor 的能力通过 Runtime trait 注入，channel、mutex、notify 这类纯 waker 驱动组件则不再跟具体 runtime 绑死。

这让 bring your own runtime 不再只是 feature flag 口号，而是可以在同一进程里给不同连接挂不同 runtime。项目还给出了 async-executor + async-io 的自定义 runtime 示例，并提供 MockRuntime 用于可控虚拟时钟测试。对 Rust 网络库来说，这种把可插拔 runtime 做到“连接级别”而不是“二选一编译开关”的方案，产品感已经比很多“runtime-agnostic”口号更扎实。

性能上，这一轮真正补齐的是 data channel。官方给出的数据里，在多连接聚合场景下，默认配置已经能跑到 Pion 的 1.70× 到 2.33×，开启 dedicated reactor 后最高到 3.24×；同时固定工作负载下峰值 RSS 和 CPU cycles 也明显下降。换句话说，这次不是只把接口重写得更漂亮，而是把性能账也算出来了。

原文链接：https://webrtc.rs/blog/2026/07/31/announcing-webrtc-v0.20.0.html

urandom：作者因可发现性与 API 取舍 fork 掉 rand，重新设计 Rust 随机数体验

Casper 写了一篇很有讨论度的文章，直接解释自己为什么 fork 了 Rust 生态里最主流的随机数库 rand，并做出了新 crate urandom。他最不满意的点不是底层算法，而是日常使用时的“可发现性”：常用操作分散在多个 trait 上，IDE 自动补全也不总能明确告诉你某个方法该在 RNG、slice 还是别的类型上找。

urandom 的做法是把高层 API 收束到一个 Random 包装器上，把 uniform、choose、shuffle 这类操作做成内建方法，而不是让用户先记住一堆 extension trait。它还把 Rng 设计成 sealed trait，不再把“任意自定义生成器都能插进来”当作默认扩展点。作者的观点很明确：多数应用真正需要的是更清晰的一组随机能力，而不是永远开放到最低层的可插拔性。

更有意思的是，这个 fork 不是只谈 API 哲学。作者还给出了一些性能和语义取舍：例如通过专门的 next_f32 / next_f64 路径，让 Xoshiro 在浮点数生成微基准里比 rand 0.10.2 跑出更高吞吐；另外它把可复现性视为公共契约，承诺同一种显式 seed 在受支持架构和语义兼容版本里保持稳定输出。即便你最后仍然继续用 rand，这篇文章也很值得看，因为它把 Rust API 设计里“灵活性 vs 可用性”的矛盾说得很透。

原文链接：https://casualhacks.net/blog/2026-07-27-why-i-forked-rand.html

Rust 编译器 2026 年 7 月提速清单：rustdoc 大降 28%，新 trait solver 个别基准压到 1 秒内

Nicholas Nethercote 更新了新一轮 Rust 编译器性能总结，统计区间覆盖 2025-12-03 到 2026-07-29。按文中的 rustc-perf 对比，整体平均 wall-time 下降了 5.59%；即便把最近很猛的 rustdoc 改进排除掉，平均仍有 2.90% 的下降。对长期盯编译器性能的人来说，这种量级已经不只是零碎优化，而是连续几个月稳定推进后的结果。

最醒目的部分来自 rustdoc：多项 PR 一起把处理 impl 的工作量压了下去，再加上把 rustdoc benchmark 纳入 PGO 训练集，最终带来一波明显下降，文中给出的 rustdoc benchmark 相对 wall-time 图大约落到了 28% 的降幅。Clippy 这边也有很实在的收益，核心思路是减少大量空 visitor 方法调用带来的虚派发成本。

另一个很值得注意的信号，是新 trait solver 在部分 benchmark 上从大约 27 秒掉到 1 秒以内。它不意味着新 solver 已经“万事俱备”，但说明这条线的性能工程正在快速推进。对每天都在跟编译时间打交道的人来说，这篇总结值得细读。

原文链接：https://nnethercote.github.io/2026/07/31/how-to-speed-up-the-rust-compiler-in-july-2026.html

Knok：把静态形状张量图编译塞进 build.rs，直接生成 Rust 类型化封装

Knok 是一个挺有想法的 Rust 项目：作者把静态形状张量图的定义放进 build.rs，在构建阶段直接追踪普通 Rust 函数、生成图、经由 MLIR 降到 IREE，最后再产出一个类型化 Rust wrapper。结果是图本身、编译产物、后端信息和 Rust 函数签名一起生成，而不是再额外维护一份模型文件和一层手写绑定。

这套方案的重点不是“Rust 也能做张量库”，而是把构建系统当成图编译入口。作者的解释很清楚：Rust 项目本来就会在 build.rs 里生成协议绑定、编译原生库、处理 shader 或打包资源，那么把张量图编译也放进同一层，其实很顺。图如果有问题，直接在 build 阶段失败；图变了，wrapper 和 artifact 一起重建；输入输出 shape 也由类型系统约束，而不是丢到运行时再检查。

目前 Knok 支持 LLVM CPU、Metal、Vulkan、CUDA 后端，还有实验性的 reverse-mode autodiff。它显然不是冲着替代 PyTorch / JAX 去的，而是更像面向 Rust 系统内嵌部署、静态 shape 推理和控制场景的一条新路线。对想把编译型 ML graph 更深地塞进 Rust 工程流的人来说，这个方向很值得盯着看。

原文链接：https://gmmyung.github.io/posts/2026-07-30-knok/