hi_sparse_bitset v0.9.0 发布：不可变位集与真正的零拷贝

hi_sparse_bitset 这次更新最值得看的点，是把“稀疏位集”继续往更适合预计算和大数据场景的方向推了一步。v0.9.0 新增了 ImmutableBitset，同时让 DirectBitset 真正支持零拷贝读取，对需要序列化、落盘和内存映射的大规模位集场景会很有吸引力。

这次版本的几个重点

• 新增 ImmutableBitset，采用线性数据结构，适合中间结果收集和预计算数据存储
• DirectBitset 配合新的序列化格式后，可以直接走真正的 zero-copy
• 所有位集容器都加入了内部“大小提示”，减少物化和原地 union 时的分配开销
• 增加对 wide::u64x8 的优化
• 配置层现在可以选择性配置数据块类型

需要注意的地方

这次版本改了序列化格式，旧数据如果依赖之前的编码方式，升级时要顺手检查兼容性。但换来的收益也很直接：更低的拷贝成本、更适合 mmap 的使用方式，以及更清晰的不可变数据路径。

原文链接：https://github.com/tower120/hi_sparse_bitset/releases/tag/v0.9.0

DualCacheFF v0.2.0 发布

DualCacheFF 是一个面向极端读写比例和抗扫描场景的并发缓存库，主打 wait-free 读路径、极低延迟和更克制的内存占用。v0.2.0 这一版把性能和工程可用性都继续往前推了一截。

版本亮点

• 核心设计基于 QSBR / RCU 思路，强调 CPU 局部性和高吞吐
• 吞吐基准里，Zipf 工作负载下可达约 6078 万 ops/s
• P99.9 延迟约 708ns，内存开销约 54.62 字节 / 项
• 移除了 crossbeam 依赖，改用自定义 wait-free 原语
• 核心引擎新增 no_std 支持，在需要 alloc 的环境里也能使用

为什么值得看

Rust 缓存库不少，但把“极端场景下的吞吐、尾延迟和内存效率”同时摆到台面上对比，并且明确说明自己牺牲了什么、换来了什么，这类项目通常更有参考价值。对做高并发基础设施的人来说，这种实现思路本身就值得研究。

原文链接：https://crates.io/crates/dualcache-ff

Raygeo：MIT 许可的 Rust/PyO3 几何库发布

Raygeo 最初是为 Rayforge 激光切割应用开发的几何库，现在已经迁移到 Rust，并继续通过 PyO3 对 Python 暴露能力。它覆盖的不是一个单点小功能，而是一整套几何处理能力：路径构建、布尔运算、曲线拟合、裁剪、轮廓分析，甚至还保留了原先项目积累下来的大量测试资产。

这个项目有几个看点

• 用 Rust 重写核心后，继续通过 PyO3 提供 Python 接口
• 支持 2D / 3D 几何路径、曲线、轮廓和多边形操作
• 集成裁剪、平滑、圆弧拟合等更偏工程侧的能力
• 设计上尽量避免把数据封装成高层 Python 对象，更强调底层性能
• 采用 MIT 许可，已有文档、GitHub 和 PyPI 发布路径

为什么它容易传播

Rust 做几何计算和图形前处理并不新鲜，但这种“Rust 做核心 + Python 做落地接口”的组合，一直都很有现实价值。尤其是当它背后已经有真实应用和大量测试时，可信度会比纯 demo 型项目高不少。

原文链接：https://github.com/barebaric/raygeo/blob/main/docs/raygeo.md

ee-editor：快速的终端文本编辑器

ee-editor 是一个用 Rust 写的终端优先文本编辑器，重点不是“又一个 TUI 编辑器”，而是把大文件能力、语言感知和插件式架构一起打包成一个更完整的工程形态。

它现在公开出来的几个重点

• 面向大文件场景设计，支持持久化 rope 存储和流式工作流
• 终端界面基于 ratatui 和 crossterm
• 语言能力由 tree-sitter 驱动，可做解析、高亮和语言感知处理
• 支持 LSP 与插件集成
• 编辑器核心与前端分离，通过 JSON/RPC 通信，便于扩展和复用

为什么这条值得收进日报

Rust 生态里的编辑器项目不少，但真正把“可扩展核心”“终端体验”和“超大文件处理”同时放在第一优先级的并不多。对喜欢终端工具链、又关心编辑器架构的人来说，这类项目通常很容易引起兴趣。

原文链接：https://github.com/ffimnsr/ee