Mike Tang·1 天前
【Rust日报】2026-07-20 Keel 0.3 发布：Rust 写的静态类型解释语言补上标准库、Map 和文档站
Keel 0.3 发布：Rust 写的静态类型解释语言补上标准库、Map 和文档站
Keel 0.3 这次更新挺像一个“从实验玩具往可用语言继续推进”的节点。作者把它定位成一门用 Rust 编写、语法接近 Rust、使用体验又想靠近 Python的静态类型解释语言，而且继续强调它在解释执行场景下的速度目标：大约能做到 Python 的 2 到 10 倍，同时维持零注解式的类型推断体验。对 Rust 社区来说，这类项目的看点不只是“又造了一门语言”，而是作者正在认真把 Rust 的编译器工程思路往运行时语言工具链上迁移。
0.3 最值得记的不是一句抽象口号，而是一批很实的工程补丁：标准库正式进包，目前先覆盖 std/math、std/time、std/random；新增 Map 类型 和对应语法；错误信息做了明显强化；编译器和 VM 也补了不少优化，像统一编译路径、统一字面量编译与寄存器分配、移除冗余边界检查之类，都说明作者已经在认真收敛内部结构，不只是往外堆功能。
另一个信号是项目的外围配套也在变完整：二进制和动态库产物一起发，文档网站和在线 playground 都补上了，说明作者已经在把 Keel 往“可以被试、可以被嵌入、也可以被讨论”的工具链方向推。虽然它离成熟生态显然还早，但如果你关心 Rust 写语言实现、轻量脚本语言嵌入 或 解释器性能路线，Keel 0.3 是这两天值得留意的一条线。
原文链接：https://github.com/horacehoff/keel
ExImg：egui/eframe 做出可点击穿透的参考图覆盖层工具
ExImg 这个项目很讨巧，因为它解决的是一个非常具体、但很多画图和设计场景都真的会遇到的小痛点：参考图总得放在旁边看，可一旦不停切窗口，流程就很碎。作者用 egui/eframe 做了一个小型图片查看器，图片可以直接拖进去或从剪贴板贴进去，窗口会自动适配尺寸、始终置顶，还能切到无边框 + 全透明背景模式，让画布上方只剩图片本身。
真正有意思的是这个“像真覆盖层一样工作”的细节处理。作者提到，为了让用户还能继续操作底下的绘图软件，项目用了 ViewportCommand::MousePassthrough 做点击穿透；但这样一来窗口失焦后，普通快捷键就很难把模式切回来，于是又借助 global-hotkey 注册系统级热键去收回控制权。这种问题不大、但一旦真做桌面工具就一定会撞上的边角料，恰恰最能说明一个 Rust GUI 项目是不是停留在 demo。
再往下看，ExImg 还把安装和发布链路顺手理了一遍：从手写 Inno Setup 转到 cargo-packager，再接 GitHub Actions 自动出 Release。它现在还是 Windows-only，但作为一个围绕 egui、窗口层级、透明窗口和系统热键组织起来的小工具，已经很像一份“可抄作业”的桌面应用样板了。
原文链接：https://github.com/NetoTTT/eximg
cair-rs：内容感知图像缩放工具把 seam carving 带回 Rust
cair-rs 走的是一条老算法重新做现代实现的路子：它把 seam carving / content-aware image resizing 这类“按内容重要性删像素列”的图像处理方法，做成了一个 Rust 项目，而且还附了在线 demo。对很多开发者来说，图像缩放早就不是新话题，但真正把“低能量接缝删除”这种内容感知路径重新做成可玩的工具，依然挺能勾起兴趣。
从仓库说明看，作者没有把它包装成特别大的平台，而是很务实地先把核心能力、示例和参考论文链接整理出来：包括 2007 年的 seam carving 论文、后续实时化研究，以及网页演示入口。这种项目的价值不在于它立刻能替代成熟图像软件，而在于它很适合作为 Rust 图像处理和算法实现的一个干净样板。
如果后面再补 benchmark、并行特性或者目标保留掩码之类能力，cair-rs 会更像一个完整的算法工具链；但就今天这个状态，它已经足够说明：Rust 社区里对“经典视觉算法重新工程化”这条路，还是有人在认真往前推。
原文链接：https://github.com/sermuns/cair-rs
Rooc：把 MILP 建模语言、Rust API 和浏览器求解工具打成一套
Rooc 的有意思之处，在于它不是只给出一个 Rust crate，然后把“更完整的用户体验”留给别人补。作者这次做的是一整套围绕线性 / 混合整数优化建模的组合：既有 Rust 侧的 fluent API，也有一门独立的 ROOC 建模语言，还有能在浏览器里直接跑的 Web 平台和 TypeScript 包。换句话说，它想做的不是单点库，而是一整条从模型描述到求解执行的通道。
从 README 能看出来，Rust 侧 API 走的是比较顺手的 builder 路线，布尔变量、整数变量、约束、目标函数这些核心拼装都做得很直接；而 ROOC 语言层则开始支持图结构、集合、索引约束、abs / min / max 这类块式表达，显然不是只想停在教学级 LP 示例。作者还把 WebAssembly 求解链路一起接进了 TypeScript 包，这意味着前端或浏览器侧的优化建模试验也能沿着同一套语义走下去。
对 Rust 圈来说，这类项目的价值不只在“又一个求解器封装”，而在它把语言层、库层、Web 交互层放到一个仓库里统一推进。要是后面文档、示例和求解后端继续补强，Rooc 很可能会变成 Rust 在运筹优化 / OR 建模方向里一个挺有辨识度的入口项目。
