yring：把 SPSC 队列原子操作从“每条一次”改成“每批一次”，吞吐冲到 17M msg/s

yring 是从作者现有项目里拆出来的一个 bounded SPSC ring buffer，核心想法是把传统单生产者/单消费者队列里“每 push / pop 都要碰原子指针”的成本，改成按批 flush / prefetch。作者直接借用了 ZeroMQ ypipe 的思路：不是只用 head / tail 两个指针，而是拆成 head / tail / flush 三个位置，让 push() 和 pop() 本身都可以做到零原子操作，真正的同步只发生在批量发布和批量可见性切换上。

这件事最有价值的地方，不只是“更快”，而是它保住了简单 API。很多高吞吐队列想提速，往往要把使用方式改成 chunk / slice 批处理；而 yring 这里仍然维持逐项 push() / pop() 的直觉式接口，只是把 flush()、prefetch() 和 release() 这些批次边界显式交给调用方。作者给出的对比很夸张：在自己的场景里，它曾把进程内消息吞吐从 3M 拉到 17M msg/s；README 基准里，64B 项目下批处理模式可到 192M items/s，对比 rtrb 的逐项 API 大致有 6x 优势，32B 下甚至能到 12x。

当然，作者也没有把它吹成“全面碾压”：如果你的代码已经能很好适配 rtrb 那种 chunk API，纯吞吐上未必打不过。但 yring 给 Rust 并发基础设施带来的启发很清楚——不是所有高性能队列都必须牺牲接口手感，只要把同步边界设计好，逐项 API 也能跑到非常激进的量级。

Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uh7er1/yring_bounded_spsc_ring_buffer_with_batched/ 项目仓库：https://github.com/paddor/omq.rs/tree/main/yring crates.io：https://crates.io/crates/yring

原文链接：https://old.reddit.com/r/rust/comments/1uh7er1/yring_bounded_spsc_ring_buffer_with_batched/

bon 两年回看：40M 下载的 builder 宏还活着，但作者开始劝你别在内部代码里乱用

bon 这个 builder 生成器，过去两年在 Rust 社区已经不算小众工具：作者在最新回顾里直接提到，它现在已经接近 4000 万下载量，功能成熟、维护压力也不大。它最早切入的点很明确：给 struct、function 和 method 生成 compile-time checked builders，让可选参数、命名参数风格调用以及 typestate 约束这些体验，能在今天的 Rust 里更顺手地落地。

但这次文章最值得看的，不是作者继续推销功能，而是他反过来认真质疑：这些问题真的值得靠 proc-macro 依赖来解决吗？ 作者现在的态度明显冷静多了：如果你是在做公开库、很在意 API 兼容性，那么 bon 依旧很有价值，尤其是在“把原本必填字段改成可选字段时尽量避免破坏调用方”这类场景上，它确实能替语言本身补坑。但如果只是内部业务代码，收益可能没你想象中那么大，反而会带来编译时间、抽象复杂度和错误信息可读性上的额外成本。

这篇回顾最妙的地方，在于它不是“作者背叛自己项目”的戏码，而是一种很少见的开源成熟信号：项目作者开始更清楚地界定自己的工具该在什么地方用、又不该在什么地方滥用。 对 Rust 生态来说，这种带着现实感的自我修正，往往比单纯宣布“功能更多了”更值得看。

文章原文：https://bon-rs.com/blog/bon-builder-generator-2-years-retrospective-is-it-worth-using 项目仓库：https://github.com/elastio/bon crates.io：https://crates.io/crates/bon

原文链接：https://bon-rs.com/blog/bon-builder-generator-2-years-retrospective-is-it-worth-using

Truce 1.0：一个 Rust 音频 / MIDI 插件框架，想把 CLAP、VST3、AU、AAX 一次性串进同一套工程流

Rust 音频生态这些年一直在长，但真正难的是把“能写 DSP”推进到“能稳定做插件工程”。Truce 1.0 想补的正是这层基础设施：它不是只给你一个处理音频 buffer 的库，而是试图把 CLAP、VST3、LV2、AU v2、AU v3、AAX 以及 standalone 这些目标格式，统一到同一份 Rust 代码和同一套 CLI 工作流里。

作者在发布帖里把定位讲得很实在：目标不是让开发者沉迷平台兼容细节，而是尽快进入 DSP / MIDI / GUI 本身。仓库文档里最有分量的地方，是它连“最后一公里”都往前做了：cargo truce 不只负责 scaffolding，还覆盖了 build / install / validate / package / screenshot / preset 这些工程动作；同时还支持 egui、iced、Slint、Vizia 等 GUI 路线，以及对 iOS AU v3 和 Pro Tools AAX 这种麻烦格式的兼容。

这意味着 Truce 1.0 的意义，不只是“又一个音频框架”，而是它开始把 Rust 在音频插件这条长期偏小众、偏手工的赛道上，往更完整的产品化开发体验推进。对既写 Rust、又碰音乐软件或插件宿主的人来说，这类工具一旦稳定，生态门槛会明显下降。

Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1ugwkr1/truce_10_release_midiaudio_plugin_framework_in/ 项目仓库：https://github.com/truce-audio/truce 文档入口：https://truce.audio/docs/

原文链接：https://old.reddit.com/r/rust/comments/1ugwkr1/truce_10_release_midiaudio_plugin_framework_in/

BlazePilot：Rust + egui 写的 Linux 文件管理器，开始把“GPU 加速 + 标签 + Git 状态”揉进一套桌面工具里

很多 Linux 文件管理器的问题，不在于不能用，而在于很难同时做到够快、够轻、又够可定制。作者这次展示的 BlazePilot，就是朝这个方向硬凿的一类项目：技术栈用的是 egui + wgpu + Tokio，重点不是模仿传统桌面壳，而是把图形加速、异步文件操作和更现代的交互组织方式放进一个更轻的 GUI 里。

从作者列出的能力看，它已经不只是“浏览文件”这么简单：有 grid / row 双视图、虚拟滚动、模糊搜索、标签系统、图片预览、Git 状态提示、UDisks2 磁盘管理、运行时语言切换、终端快捷打开，以及基于 JSON 的主题系统。README 里还专门提到用了 MiMalloc 控制碎片、Tokio 保证文件操作不阻塞 UI，并做了目录 LRU 缓存、缩略图磁盘缓存和 SVG 图标并发渲染这些偏工程化的优化。

它当前当然还不是“Linux 下的新标准文件管理器”，作者自己也承认主题一致性和一些视觉细节还在持续打磨。但这个项目值得看的地方，在于它把 Rust 桌面应用一个很现实的方向展示出来了：不是只做 demo GUI，而是真在冲击日常可用的桌面生产力工具。

Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uh196n/blazepilot_a_gpuaccelerated_file_manager_for/ 项目仓库：https://github.com/Jhanfer/blazepilot Releases：https://github.com/Jhanfer/blazepilot/releases/latest

原文链接：https://old.reddit.com/r/rust/comments/1uh196n/blazepilot_a_gpuaccelerated_file_manager_for/