SteelMC：Rust Minecraft 服务器区块生成速度达到原版 18.8 倍

这不是那种“刚建仓库就宣布重写世界”的 Rust 项目。作者把 SteelMC 悄悄做了九个月，等到它已经能让玩家真正连进来、加载持久化世界、和方块与背包交互、并把地形生成跑到 block-for-block 接近原版一致，才正式公开。最硬的一组数据，是它在 7500 个随机区块上的地形一致性测试，以及一台 Ryzen 9 9950X 上对 10201 个新区块的生成基准：Steel 平均每秒 2582 个区块，冷启动吞吐量约是 Fabric + Chunky 的 18.8 倍。

更值得 Rust 圈关注的，其实不是“更快”三个字，而是作者怎么把复杂世界生成问题拆成可以被系统化控制的并发流水线。文章详细讲了它如何把 Minecraft 的分阶段区块依赖重构成一个 chunk pyramid 调度模型，再把跨区块特性、光照传播、后台 IO、主线程 tick handoff 这些最容易互相卡住的部分拆开处理。甚至连 vanilla 里某些看似偶然、但已经被红石玩家当成特性的行为，它也明确选择“保留 bug-compatible 行为”，而不是为了整洁硬改规则。

这类项目的意义很大：它说明 Rust 在游戏后端里不只是“性能语言”，而是能把 并发调度、确定性、可维护的系统边界 一起往前推。对做多人游戏服务端、仿真系统、复杂状态机调度的人来说，这篇公开设计说明非常值得细读。

原文链接：https://steelmc.dev/blog/announcement/

PidgeIoT：用 workers-rs + Dioxus 把 Rust 从云端一路铺到 IoT 控制台

PidgeIoT 这篇分享很有现实工程味。作者做的是一个开源 IoT 设备管理平台：设备注册、shadow 配置下发、可查询遥测历史、邮件告警、OTA 固件更新，一整套云侧实现都用 Rust 打通。技术栈也很有代表性：后端是跑在 Cloudflare Workers 上的 workers-rs，每个设备对应一个 Durable Object；前端则是 Dioxus 0.7 的 WASM SPA；中间再用一个共享 serde 类型 crate 把前后端数据结构绑在一起。

这里最值得抄作业的点，是作者把“Rust 前后端同构”讲得非常具体：数据库侧用 *Row 结构承载原生时间戳与存储类型，对外 API 再映射成 RFC 3339 等更友好的表示，中间靠 From 转换衔接。这样一来，加字段时编译器会直接把所有漏改的地方都揪出来，不需要 OpenAPI 代码生成，也没有 schema drift。除此之外，文章还很坦诚地复盘了 workers-rs 和 Dioxus 0.7 在生产环境里踩过的坑，比如 SqlCursor::one() 的异常行为、CORS 头拼接、SSG hydration 丢 query 参数、以及 wasm-split 看似漂亮但实际无法上线的问题。

设备认证设计也很漂亮：作者没有套 JWT，而是给每台设备分配独立 Ed25519 密钥对，token 只保留版本号、过期时间和签名，既省解析成本，也把“轮换即撤销”这件事做得很自然。对想用 Rust 同时覆盖边缘云函数、管理后台和设备平台的人来说，这篇经验帖参考价值很高。

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

multicalc：把 no_std Rust 科学计算栈直接推到 1kHz 实时控制环

multicalc 这条很容易被低估。作者做的不是单点数学库，而是一整套面向 实时嵌入式系统 的科学计算组件：估计、控制、运动学、Lie 群、微积分、自动微分、线性代数，全部放在稳定版 no_std Rust 里，而且目标非常明确：无堆分配、无 panic、无 unsafe。为了证明这不是“API 看上去很完整”的纸面项目，作者直接给出了一个很硬的实战场景：2D 机器人先用 2000 粒子的粒子滤波在噪声激光雷达下做定位，再用 5 状态 EKF 融合轮速、IMU 和 GPS，最后用 Follow-the-Gap 控制器在障碍赛道上跑到 60 万 tick 零碰撞。

文章最吸引人的，是它把嵌入式 Rust 常见的几组矛盾压到了一起：既要高频控制，又要可验证；既要 no_std，又要覆盖足够多的数值方法；既要追求性能，又不愿为了“快一点”把 unsafe 和 panic 风险偷偷带进库边界。作者的做法是把所有类型固定尺寸、所有调用工作量做成有界，并且在 x86_64、aarch64 以及多种 bare-metal ABI 上持续测试，再拿 numpy、scipy、filterpy 的结果做近似 1 ulp 的对照校验。

如果你关心 Rust 在机器人、控制系统、嵌入式数值计算里的真实上限，这个项目很值得盯。它已经不只是“Rust 也能做一点控制论”，而是在尝试把一整层实时控制数学基础设施系统化地带进 Rust。

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

OMQ.rs：不靠 libzmq，纯 Rust 复刻一整套 ZeroMQ 架构与传输栈

OMQ.rs 这条很对基础设施工程师胃口。作者想做的不是“给 ZeroMQ 包一层 Rust binding”，而是把 libzmq 那套使用体验和架构风格，原生重做成纯 Rust 实现：同样的 socket model，同样的 connect / bind / send / recv 形状，支持 connect-before-bind、自动重连、多传输透明切换，同时不再依赖 C 编译器和 libzmq 本体。

从当前能力看，这已经不是玩具了：项目覆盖了 20 种 socket 类型、9 种传输方式，安全层支持 NULL、PLAIN、CURVE，既有异步 socket，也有阻塞 socket，还有 Python binding 和 libzmq 兼容 C API。内部核心 omq-proto 走的是 sans-I/O ZMTP 3.x 设计，再由 omq-tokio 接入 Tokio。作者还专门强调了热路径上的 yring：一个有 batched flush/prefetch 特性的有界无锁 SPSC ring，用来把批处理收益藏在内部，而不把复杂度甩给 API 使用者。

更妙的是，这个项目甚至把压缩层也顺手工程化了。它支持透明的 LZ4 传输，并且可以从前期消息训练字典，再把字典下发到对端后用于后续流量压缩。再加上 700+ Rust 测试、协议 fuzz、Loom/Miri 验证、以及和 libzmq / zmq.rs / rzmq 的对比基准，OMQ.rs 已经显露出“Rust 消息中间件底座候选”的味道了。

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