Ante：想把借用检查和引用计数真正揉到一起，且不靠运行时崩溃兜底

Ante 这篇新文最抓人的地方，不是又造了一门“更像 Rust 的语言”，而是它试图碰一个很多人默认做不到的组合：把 borrow checking 和 reference counting 真正混在一起，同时尽量不把安全性推给运行时 panic 或独占性检查。作者的目标很明确——希望既能保留借用检查的静态安全感，也能在需要更灵活对象图时，引入类似 RC 的共享能力，而不是一上来就掉进 Rc<RefCell<_>> 这种“能跑，但运行时还可能炸”的折中方案。

文章里最重要的设计点，是 Ante 把结构体和联合体分开处理，并引入了 shape-stability、uniq 临时独占引用这些机制。它允许某些共享可变场景在编译期被理解，而不是像 Rust 的 RefCell 或 Swift 的 exclusivity checking 那样，到运行时再判断“这次借用会不会撞车”。作者反复强调，这件事真正有价值的地方不是语法新鲜，而是让共享可变数据也有机会维持静态可验证的安全边界。

当然，这还远不是“明天就能落地替代 Rust”的成熟方案。作者自己也承认 Ante 仍在快速演化，很多部分还在理论和实现之间摇摆。但如果只看编程语言设计层面，这篇文章确实把一个老问题重新点亮了：内存安全语言未必只能在“严格借用”与“灵活共享 + 运行时检查”之间二选一。对 Rust 社区来说，这类尝试即使暂时不直接变成生产工具，也很值得盯一眼。

文章原文：https://verdagon.dev/blog/ante-blending-borrowing-rc 项目主页：https://antelang.org/ Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1ui2u0x/ante_a_new_way_to_blend_borrow_checking_and/

原文链接：https://verdagon.dev/blog/ante-blending-borrowing-rc

Krokiet/Czkawka/Cedinia 12.0：Rust 清理工具线继续扩张，Android 版和图片对比一起补上

Krokiet / Czkawka / Cedinia 12.0 这波更新的重点，不只是“功能又多了一些”，而是作者开始明确推动整条产品线转向 更 Rust-native 的 UI 路线。桌面端上，老 GTK 版 Czkawka 基本被视作阶段性收尾；作者直说继续维护 GTK 版本已经越来越不划算，跨平台构建、稳定性和 UI 问题都在拖后腿。取而代之的，是基于 Slint 的 Krokiet，以及这次新冒出来的 Android 端 Cedinia。

这次版本里最有传播力的新点有两个。第一，Cedinia 把“纯 Rust 图形 Android 应用到底能不能实做”往前推了一步：目前已经能做重复文件、相似图片、空文件等扫描清理，虽然视频相关功能还受限于 Android 环境里的 ffmpeg 缺失，但整体上已经不是 demo 级别。第二，桌面端的 Krokiet 补上了图像对比工具、右键菜单、翻转/镜像/旋转相似图识别、按音频比对相似视频等能力，让它不再只是 GTK 版的替代品，而开始反超旧前端。

这条产品线值得看的地方，在于它越来越像一个真实的 Rust 应用栈实验场：底层复用去重核心库，上层同时推进桌面和移动端，再把 Slint、JNI 桥接、跨平台打包这些现实工程问题一并踩过。对 Rust GUI 生态来说，这种不是“演示一两个窗口”，而是持续把桌面工具和 Android 工具做深的项目，信息量很高。

文章原文：https://medium.com/@qarmin/krokiet-czkawka-12-0-6fa09c43c3b9 项目仓库：https://github.com/qarmin/czkawka Releases：https://github.com/qarmin/czkawka/releases Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uhyg4d/krokietczkawkacedinia_120_new_android_app_image/

原文链接：https://medium.com/@qarmin/krokiet-czkawka-12-0-6fa09c43c3b9

Test That!：从 GoogleTest Rust 分叉出来，把断言 API 和失败诊断重新做顺

Test That! 是从 GoogleTest Rust 分叉出来的新断言库，但它不是简单换壳重发。作者这次想修的，是自己当年参与推动 GoogleTest Rust 时遗留下来的一个核心问题：当 matcher 组合越来越复杂时，断言 API 的“心智负担”开始明显上升。在博客和 Reddit 帖里，他重点展示的是更顺手的 matcher 组合方式，以及失败时更直接、可读的诊断输出——比如 each(gt(0)) 这种表达，不只是能写，还能把“第几个元素错了、为什么错”说明白。

更关键的是，作者并没有停留在“更好用”这层口号上，而是把分叉理由说得很具体：GoogleTest Rust 后续版本里，为了解决某些类型系统边角问题，引入了一套更绕的引用 / matcher 交互语义，结果导致开发者在写测试时要频繁思考 eq(123)、eq(&123)、matches_pattern! 到底该怎么搭。Test That! 的方向则是反过来，把 API 重新拉回“写测试不该消耗太多脑力”的初衷，同时保留 matcher 组合的表达力。

从生态角度看，这不只是又一个测试工具，而是一次对 Rust 测试体验的再整理：依赖可以全关、常用 matcher 更自然、HashMap 和容器匹配写法也更统一。对那些已经觉得 assert_eq! 太浅、但又不想为了高级断言把测试代码写得像类型体操的人来说，这个分叉项目相当值得关注。

文章原文：https://hovinen.me/announcements/2026/06/24/introducing-test-that.html 项目仓库：https://github.com/hovinen/test-that crates.io：https://crates.io/crates/test-that Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uhuhsb/introducing_test_that_a_powerful_test_assertion/

原文链接：https://hovinen.me/announcements/2026/06/24/introducing-test-that.html

multicalc 0.6.0：no_std 多元微积分库继续打磨，还把贡献入口整理成了可接力状态

multicalc 0.6.0 不是那种靠标题一眼炸开的项目，但它的价值挺扎实：这是一个面向 single / multi-variable calculus 的 Rust 库，覆盖数值微分、积分、Jacobian、Hessian、向量微积分和 Taylor 近似，而且目标环境直接瞄准 no_std / 零堆分配 / 无 panic。这意味着它不只是给桌面科学计算准备的，还在认真照顾裸机、嵌入式和机器人一类更挑运行环境的场景。

0.6.0 这次更新的重点，主要在“把接口和边界条件一起收干净”。作者把 integrand API 简化成泛型 Fn(...) 路线，去掉了多余的运行时参数；同时给迭代积分器补上了无穷和半无穷积分区间支持，又修了一批积分核、线积分、近似公式和边界检查上的 bug。更难得的是，项目没有只停在“修好了”，而是顺手把每个模块的 runnable example、criterion benchmark、no_std 目标和 MSRV CI 一并补齐。

另一个很像成熟开源维护者的动作，是作者把后续路线图和贡献入口讲得非常明确：接下来要做 dual-number 自动微分、定长线代、ODE 求解、符号数学、机器人运动学和优化，并且已经把 backlog 拆成了清晰 issue。对 Rust 科学计算方向来说，这类既顾运行时约束、又愿意把贡献门槛整理低的库，很容易慢慢长成基础设施。

crates.io：https://crates.io/crates/multicalc Docs：https://docs.rs/multicalc 项目仓库：https://github.com/kmolan/multicalc-rust Reddit 讨论帖：https://old.reddit.com/r/rust/comments/1uib5io/multicalc_060_a_no_std_multivariable_calculus/

原文链接：https://crates.io/crates/multicalc