Rust PNG crate 再提速：已进入 GNOME 与 Chromium 默认链路

Rust 生态里的 png crate（image-png）过去一年不只是继续提速，还真正进入了超大规模生产环境：作者在新博文里确认，它已经自 Chromium M139 起成为 Chromium 各平台默认 PNG 实现，同时也随着 glycin / image-rs 的推广，进入了越来越多 GNOME 应用的默认图像加载路径。

这次更新最值得关注的点有几个：

• 在解码性能上，image-png 依旧保持很强优势。文中基于 2848 张图像语料给出的数据里，Ryzen 9 7950X 上可达 410.8 MP/s average / 339.9 MP/s geomean，Apple M4 上可达 387.7 MP/s average / 310.5 MP/s geomean，继续领先 libpng、stb_image、spng 等传统 C 实现
• Chromium 采用它并不只是因为“Rust 更安全”，还要求它在 功能、兼容性、正确性、性能 上都不能掉链子。为满足浏览器场景，项目补齐了 部分下载时的中间解码状态显示，并加入了 mDCV / cLLI 等新 chunk 支持
• GNOME 方向的价值点则更偏向 内存安全 与 APNG 支持。由于上游 libpng 长期没有内建 APNG，很多 Linux 桌面应用此前并不能默认支持动画 PNG；切到 image-rs / glycin 路线后，这个短板被真正补上
• 性能提升背后并不神秘，主要来自 原地 unfilter、更合理的内部 buffer 尺寸、对 interlacing 的专项优化，以及 simd_adler32 / crc32fast 等生态组件对 AVX-512、NEON 的进一步利用

这条新闻真正有传播力的地方在于：它再次证明了 内存安全实现并不必然牺牲底层性能，而且 Rust 图像基础设施已经不只是“实验室成绩好看”，而是被桌面与浏览器主线真正吃进去了。

文章链接：https://blog.image-rs.org/2026/06/18/png-adoption.html 项目链接：https://github.com/image-rs/image-png/

原文链接：https://blog.image-rs.org/2026/06/18/png-adoption.html

ClickHouse 谈在 150 万行 C++ 数据库里引入 Rust：不是重写，而是可审计增量接入

Rust in Production Podcast 新一期找来了 ClickHouse 创始人 Alexey Milovidov 和长期维护 sqlx 的 Austin Bonander，聊的是一个很多团队都关心的问题：当你的主系统已经是 150 万行、每天跑数千万测试的 C++ 代码库 时，Rust 究竟该怎么进场？

这期内容最有价值的地方，不在于“Rust 很棒”的空泛表态，而是把大型存量系统引入 Rust 的现实阻力摊开讲了：

• ClickHouse 并没有把 Rust 当作“一把梭的重写按钮”，而是优先考虑 把 Rust 组件以可审计、可复现、能满足合规要求 的方式接入现有 C++ 服务
• 讨论里反复提到 Cargo 与 CMake 的边界。对多语言 monorepo 来说，语言本身往往不是最难的，真正麻烦的是 构建系统、依赖供应链、FIPS 合规、可重现构建 这些工程现实
• 节目里还专门提到 Corrosion 这类 CMake ↔ Rust 集成方案，以及 ring、delta-kernel-rs、h3o 等案例，说明 ClickHouse 看重的不是“会不会写 Rust”，而是 Rust 组件能否在已有基础设施里稳定落地
• Austin 本身同时维护 sqlx、参与 ClickHouse Rust 工具链，这让节目兼具数据库一线实践与 Rust 工程生态视角，信息密度相当高

这条内容的意义在于，它给很多大型基础设施团队提供了一个更现实的范式：Rust 的进入方式未必要从重写开始，更可能是从局部、受控、可复现的关键路径切入。

节目页面：https://corrode.dev/podcast/s06e06-clickhouse/ ClickHouse 仓库：https://github.com/ClickHouse/ClickHouse 相关 Rust 客户端：https://github.com/ClickHouse/clickhouse-rs

原文链接：https://corrode.dev/podcast/s06e06-clickhouse/

soa-rs 1.0.0 发布：用 Rust 宏把 Struct of Arrays 做成可落地容器

soa-rs 发布了 1.0.0，核心目标很明确：把 Rust 里常见、但经常要手搓样板代码的 Struct of Arrays（SoA） 数据布局，做成一套更容易在真实项目里落地的容器与派生宏方案。

这次 1.0.0 虽然不是那种“大而全”的重写版本，但几个更新方向都很实用：

• 新增 SoaClone derive macro，让 SoA 类型在需要复制时更自然，不必再围着内部字段自己补样板逻辑
• 改进了 extend 路径里的 size hint 使用方式，意味着批量追加数据时可以更稳地减少不必要的分配与搬运
• 修正了 soa![Foo; n] 在 n > 2 时的行为，让这个宏在更一般化的批量构造场景下按预期工作
• 从 release note 也能看出，项目已经不只是作者一人玩具，开始有外部贡献者参与 1.0.0 的打磨

SoA 这类话题表面上不如“新框架发布”显眼，但它对 ECS、数值计算、批处理、cache-friendly 数据访问 都很关键。soa-rs 做到 1.0，意味着 Rust 生态里这块“高性能布局工具”又多了一个更成熟的选择。

发布说明：https://github.com/tim-harding/soa-rs/releases/tag/1.0.0 项目仓库：https://github.com/tim-harding/soa-rs

原文链接：https://github.com/tim-harding/soa-rs/releases/tag/1.0.0

meon：扁平化、零拷贝、声明式的 Rust 文本解析引擎

meon 是一个很有意思的新项目，作者把它定义成 flat, fast, declarative parsing engine：它不走传统“先建 AST，再遍历节点”的路，而是把解析结果直接组织成 Struct of Arrays 风格的扁平表结构，让不同元素类型各自存放在独立连续数组里。

项目的设计亮点很鲜明：

• 对 Markdown 或其他文本格式来说，解析结果不是一棵 heterogeneous tree，而是像 headings、links、bolds、bullet_items 这样按类型拆开的连续 Vec，访问某一类元素时更接近顺序扫描，cache 友好得多
• 所有元素本质上都是指向原始字节切片的 Span { start, end }，也就是 零拷贝偏移引用；真正需要转成字符串时再解引用
• 项目提供 define_parser! 宏，在编译期生成 parser、content struct 与 find_* 迭代器，强调 没有运行时解释器、没有 vtable、没有额外分发开销
• 文档里还给出了 meon-md、benchmarks、fuzzing 等配套内容，说明这不是只停在概念层面的 parser toy，而是在认真往可测、可 benchmark、可扩展的方向走

从工程角度看，这个项目最值得关注的不是“又一个 Markdown 解析器”，而是它在尝试回答一个更底层的问题：如果把 Rust 的数据布局思维和编译期生成能力真正用到文本解析里，能不能绕开传统 AST 模型的性能包袱？

项目仓库：https://github.com/vgnapuga/meon crates.io：https://crates.io/crates/meon 架构说明：https://github.com/vgnapuga/meon/blob/main/ARCHITECTURE.md

原文链接：https://github.com/vgnapuga/meon

---

From Rust中文社区 Mike

社区学习交流平台订阅：

• Rustcc论坛: 支持rss
• 微信公众号：Rust语言中文社区