Dimforge Q2 2026 技术报告：Nexus 跨平台 GPU 多物理引擎开始用 rust-gpu 跑起来

Dimforge 这份 Q2 技术报告里，最值得 Rust 社区关注的新东西，就是 Nexus 终于作为新旗舰项目正式亮相。它不是一个只跑原型 demo 的实验仓库，而是一个面向 跨平台、GPU、多物理场景 的新引擎：同一套体系要同时覆盖原生桌面、浏览器、机器人、机器学习训练等方向。对已经熟悉 Rapier / Kiss3d 的开发者来说，这基本可以看作 Dimforge 在“Rust 物理 + 图形 + WebGPU”这条线上的一次明显升级。

这套方案最有传播性的点，在于它把 shader 这一层也尽量往 Rust 侧收拢了。报告明确写到：Nexus 的 shader 是 100% Rust 编写，底层用了 rust-gpu、khal 和 vortx，而不是继续把核心逻辑留在 WGSL。Dimforge 给出的理由很直接：他们试过 WGSL、WESL、Slang 这些方案，但无论是 IDE 体验、跨 crate 复用，还是 CPU/GPU 结构对齐、调试便利性，最后都没有 Rust 方案顺手。更关键的是，这一版 Nexus 相比他们之前的 WGSL 路线，报告里明确给出一个很抓眼球的结果：整体大约快 2 倍，而且浏览器和原生之间的性能落差也更小。

能力层面也不只是“把 Rapier 搬上 GPU”这么简单。Nexus 现在已经支持 multibody joints、多 collider、动态插入刚体，还内建了 batch simulation，可以并行跑同一场景的成千上万个变体，明显就是在对准强化学习、训练数据生成和机器人仿真这类需求。配套 viewer 则建立在 Kiss3d 上，并且尽量避免 GPU→CPU 同步，把模拟和渲染都留在 GPU 上完成。报告里还特别提到，他们已经能用这套东西训练简单双足机器人完成站立和行走。

除了 Nexus，本季度 Dimforge 还把 Rapier 和 Kiss3d 一起往前推了一截：Rapier 0.34 增加了新的 PhysicsWorld 封装，开始更系统地补多体系统和 MJCF 支持；Kiss3d 则继续增强渲染效果，甚至上了硬件加速 path tracer。把这些拼起来看，这已经不是单点项目更新，而是在构 Rust 自己的跨平台科学计算 / 机器人 / 图形物理基础设施栈。

原文：https://dimforge.com/blog/2026/07/01/dimforge-Q2-technical-report 项目仓库：https://github.com/dimforge/nexus 在线演示：https://nexus.dimforge.com/demos

原文链接：https://dimforge.com/blog/2026/07/01/dimforge-Q2-technical-report

TrueFix：Rust 版 FIX 协议引擎对齐 QuickFIX/J，卖方 / Acceptor 终于不是陪跑

今天这条更偏金融基础设施，但技术含量不低。作者发布的 TrueFix，目标非常明确：做一个 生产可用 的 Rust FIX 协议引擎，而且不是只做买方 / initiator 方向的轻量封装，而是把 卖方 / acceptor 也当成一等公民认真做。作者在帖子里点名了现有 Rust 方案的空缺：要么更偏 initiator，要么还停留在 pre-1.0、离“真上生产”还有点距离，所以他干脆自己补了一套。

TrueFix 最能打的一点，是它不只是“号称对齐 QuickFIX/J”，而是把这个口号具体化成了 验收测试门槛。项目把 QuickFIX 的 acceptance test 路线移植了过来，并把它作为 release gate。仓库里给出的状态更猛：现在已经覆盖到 373 / 373 个场景，横跨 9 个 FIX 版本，并把这套 conformance 当成硬约束，而不是 README 里的 marketing 文案。对于 FIX 这种协议栈来说，这种“先把一致性打穿”的思路，本身就很容易建立信任。

架构上，TrueFix 也不是只把 parser 和 session state machine 拼起来就算了。它支持 FIX 4.0–5.0SP2 + FIXT 1.1，底层用统一的 dictionary 管线同时做 运行时校验 和 构建期 typed message codegen；运行层跑在 tokio 上，TLS 走 rustls，存储支持 Postgres / MySQL / SQLite，配置则尽量对齐传统 .cfg 启动模式，目标是把一个完整 engine 的启动复杂度尽量压缩到“配置驱动 + callback 填业务”这个层级。对一直想看 Rust 进入交易系统底座的人来说，这条很有分量。

更有意思的是，作者没有把“稳定”理解成保守，而是往工程硬度上继续加码：关键路径禁 panic/unwrap、workspace 级禁用 unsafe、支持 multi-session / dynamic sessions、TLS / mTLS、metrics export、failover、代理、背压等能力。它未必会立刻替代 QuickFIX/J，但至少说明 Rust 在金融协议引擎这种传统上很重 Java/C++ 的区域里，已经开始有人认真补齐“可以上线”的那一块了。

项目仓库：https://github.com/zhangjiayin/truefix Reddit 讨论：https://old.reddit.com/r/rust/comments/1un9ztx/truefix_a_productiongrade_fix_protocol_engine_in/

原文链接：https://github.com/zhangjiayin/truefix

memsafe v1.0.0：把 Secret 锁进受保护内存页，防 swap、防 core dump、闲置时直接不可读

安全类 crate 每隔一段时间都会冒出来，但 memsafe 这次做法比较硬核。它想解决的不是“drop 时帮你 zeroize 一下”这么基础的问题，而是进一步把 secret 真正放进 受保护的内存页：避免被 swap 到磁盘、避免进 Linux core dump、闲置时直接把页权限切到不可访问，甚至在 Unix 上连你自己的进程都不能在未解封状态下随手读到它。这个方向一下就把它和常见的 zeroize / secrecy 之类区分开了。

作者对这个 crate 的产品定义也很清楚：如果你的敏感信息还待在 String / Vec<u8> 这种普通堆内存里，即便你后面做了清理，泄漏面也还是偏大。所以 memsafe 提供的 Secret<N> 会尽量把 secret 直接写进受保护页，避免先落到常规 heap；对于已经持有 owned bytes 的情况，也会在复制后对源数据做显式 zeroization。底层则结合 mlock / VirtualLock、mprotect、MADV_DONTDUMP 等机制，把“不要换出、不要出现在 dump 里、非使用期不可读”这些目标串成一套更完整的防护链。

更难得的是，作者没有把它吹成“万能安全方案”，而是把 trade-off 写得很实。README 里直接给了 benchmark：创建一个 64B secret 大约要微秒级，单次读写 guard 也大约是 1 微秒 量级，远高于普通 heap，但对 API key、token、密码这类低频访问场景仍然很值。与此同时，它也明确列出不防什么：比如 root / ptrace、休眠落盘、侧信道、寄存器残留等。对安全工具来说，敢把边界讲清楚，本身就是加分项。

如果说很多 Rust 安全 crate 解决的是“语言层的误用”，那 memsafe 更像是在把 OS 级内存保护 包装成一个更不容易用错的安全抽象。对于需要在本地长期持有密钥、令牌、认证材料的桌面应用、CLI、代理服务来说，这类库会很有吸引力。

项目仓库：https://github.com/po0uyan/memsafe crate 地址：https://crates.io/crates/memsafe 文档地址：https://docs.rs/memsafe

原文链接：https://github.com/po0uyan/memsafe

p2p-tunnel：基于 Iroh 的点对点内网穿透，npx 一条命令把本机端口分享出去

这条项目不大，但切的问题非常实用。作者用 Iroh 做了一个叫 p2p-tunnel 的小工具，目标不是再造一套复杂公网代理，而是把开发者最常见的一个动作做轻：把本机某个 localhost 端口，尽量无痛地临时分享给另一台机器。如果你平时为了演示一个本地服务，经常要在云主机、中转层、Ngrok、Cloudflare Tunnel 之间兜圈子，这个方向会很有代入感。

它的使用方式也刻意压到了最短路径。你可以本地直接跑 cargo run -- share 3000，也可以不装全局包，直接 npx p2p-tunnel share 3000；另一边拿到生成的 ticket 后，再执行 connect <TICKET> 就能接进来。项目 README 里还专门强调了 npm installer 和 cargo-dist 这套发布流程，明显就是想降低“Rust 工具很好，但同事装起来太麻烦”的现实门槛。

从传播性上说，这类项目打动人的并不是技术新颖度，而是它把 Iroh 这种 Rust P2P 能力 包装成了一个开发者马上能试的 end-user 工具。相比“看起来很强、但要自己读一堆 API 才能上手”的底层库，这种面向最终场景的小工具更容易让人迅速建立直觉：Rust 做网络工具，不只是高性能 server，也能做这种拿来就用的 developer utility。

现在的功能还很克制，比如 connect 默认只绑定到本地 127.0.0.1:8080，但作为第一版，它已经足够把“点对点分享本机服务”这个价值讲清楚。如果后面再补权限控制、更多端口策略、会话管理，这条线完全有机会变成不少开发者的轻量备用隧道工具。

项目仓库：https://github.com/drmikesamy/p2p-tunnel npm 地址：https://www.npmjs.com/package/p2p-tunnel Reddit 讨论：https://old.reddit.com/r/rust/comments/1un8hbi/a_p2p_alternative_to_ngrok_or_cloudflare_tunnels/

原文链接：https://github.com/drmikesamy/p2p-tunnel