文章《改进 Rust 编译器增量系统》
作者：Alejandra (a.k.a @blyxyas)
这是今年杭州 RustChinaConf 演讲的文字版，概要：
-
痛点分析 ：当前
cargo check后运行build仍会重复大量计算，且 Cargo 常因无关微小变动触发不必要的依赖重编。 -
原子级控制：引入 "Atomic Levels" 让编译器按需执行至特定阶段（如仅 AST 或 HIR），实现不同命令间的缓存高效复用。
-
数据依赖优化：将链接参数等配置作为惰性检测的"叶子"节点，防止非关键参数变更导致早期编译阶段失效。
-
两阶段指纹：通过仅编译至"名称解析"阶段来精准判断依赖变更是否影响下游，避免无效的级联重编。
阅读：https://blog.goose.love/posts/improving-the-incremental-system-in-the-rust-compiler/
演讲：https://www.bilibili.com/video/BV1yFn8z4E2m/
文章《回顾 2012 年的 Rust》
这篇文章通过回顾 2012 年（约 v0.5 版本）的旧教程，展示了 Rust 语言的剧烈演变：
-
奇异语法 ：当时使用
@表示 GC 托管指针，~表示唯一指针，uint代替usize，甚至continue被称为loop。 -
内置运行时：拥有轻量级"绿色线程"和类似 Erlang 的任务链接机制，后为实现零开销抽象而彻底移除。
-
系统差异 ：没有 Cargo，借用检查仅关注有效性而非别名控制，且存在
do块等类似 Ruby 的控制流特性。 -
总结：作者感叹 Rust 成功抛弃了复杂的运行时包袱，转型为现代精简且安全的系统级语言。
阅读：https://purplesyringa.moe/blog/a-look-at-rust-from-2012/
讨论：https://www.reddit.com/r/rust/comments/1p6k380/a_look_at_rust_from_2012/
采访《丰田"先锋地"选择了 Rust》
这篇来自 Filtra.io 的采访文章对话了 Woven by Toyota 的资深软件工程师 Pete LeVasseur，重点讨论了 Rust 在丰田未来汽车软件中的核心地位。
主要内容总结：
-
战略定位 ：Woven 作为丰田的"技术先锋"，正在构建统一软件平台 Arene，旨在实现跨车型的软件一致性和无缝更新。
-
选择 Rust：丰田视 Rust 为未来的关键技术，利用其内存安全特性开发安全关键（Safety-Critical）系统，以替代传统的 C++。
-
社区投入：公司不仅制定了内部编码标准，还积极投资 Rust 生态，包括参与"安全关键 Rust 联盟" (Safety-Critical Rust Consortium)。
-
量产里程碑：采访确认了 Rust 代码即将部署到丰田的量产车中，标志着其从研发走向实际应用的重要一步。
阅读：https://filtra.io/rust/interviews/woven-by-toyota-nov-25
资讯：Rust for Linux 内核共同维护者 Alex Gaynor 正式卸任
Alex Gaynor 是最早尝试使用 Rust 编写 Linux 内核模块的开发者之一。由于时间不足，他已经暂时离开了 Rust Linux 内核的开发，现在正式卸任 Rust 代码的共同维护者一职。
Rust for Linux 项目当前负责人 Miguel Ojeda 成为该代码的唯一官方维护者，此外还有几位 Rust 代码审查员。
阅读：https://www.phoronix.com/news/Alex-Gaynor-Rust-Maintainer
rust-fontconfig：纯 Rust 编写的 Linux fontconfig 替代库
这是一个 Linux fontconfig 库的纯 Rust 重写项目：
-
零依赖优势：完全移除了对 C 语言库（如 freetype、expat）及构建工具的系统依赖，解决了跨平台编译痛点，支持 Windows、macOS 及 WASM，且易于静态链接。
-
安全与高性能：利用 Rust 内存安全特性降低恶意字体攻击风险，并通过多线程和内存映射技术优化，实现约 90ms 的缓存构建与 4µs 的极速查询。
-
核心功能 ：基于
allsorts解析器，支持按名称、样式及 Unicode 范围进行精准的字体匹配与回退 ，提供no_std支持，并包含 C API 绑定以便集成。
仓库：https://github.com/fschutt/rust-fontconfig
coral：使用 portable-simd 实现的完全安全的 BLAS 库
-
核心定位 ：一个完全使用 Rust 编写的 BLAS（基础线性代数子程序）库。
-
架构专注 ：专为 AArch64（ARM 64位）架构设计并进行了深度优化，旨在充分挖掘该平台的计算潜力。
-
零依赖优势 ：坚持 100% Rust 代码实现且没有任何外部依赖，解决了传统 BLAS 库配置复杂的痛点，易于集成。
-
性能目标：在保持 Rust 语言安全性的同时，致力于提供与现有 C/Fortran 实现相媲美的卓越运算性能。
仓库：https://github.com/devdeliw/coral/
讨论：https://www.reddit.com/r/rust/comments/1p6hs7l/a_fully_safe_rust_blas_implementation_using/
讨论：为什么这么多 WGPU 函数在遇到无效输入时会引发 panic 而不是返回结果？
"这是一个很好的问题，也是我们面临的比较棘手的限制之一。因为我们希望简化 Web 应用的发布流程，所以需要为 Web 和原生应用提供统一的接口。WebGPU 实际上在一个完全独立的进程中执行所有 GPU 工作，因此所有操作本质上都是异步的。每次从 GPU 进程切换到内容进程（例如返回错误）时，都需要异步处理，以避免阻塞内容进程。WebGPU 实现这一点的方式是通过错误作用域（error scope ）异步返回错误，或者通过未捕获的错误回调（uncaptured error callback ）。
这些工具在原生应用中也能运行，但这些方法是异步的，所以你需要使用类似 pollster::block_on 将它们转换回同步。在原生应用中，实际上并没有发生异步操作（所有操作都在你调用的函数中完成，只是被放入了一个立即解析的 future 对象中），但为了保证移植性，我们必须遵循更强大的接口。
这是一个常见的症结所在，我们可以在向用户传达我们的错误处理方式方面做得更好，或者可以提供一些实用工具，使原生应用更容易处理错误。
------ wgpu 维护者"
"验证和结果检查都会影响性能。虽然影响不大，但也不是没有代价的。在正常的应用程序流程中，这是完全可以接受的代价。但在 GPU 库中，你通常不希望每一帧都承受这种额外的开销。更糟糕的是，你经常需要在每一帧中使用复杂的循环逐块绘制。在这种规模下，这些开销累积起来就相当可观了。
对于某些函数调用，错误的输入可能已经以代价非常高昂或完全无法恢复的方式搞乱了管道，而 panic 则要容易得多。
记住，GPU 的本质是超高速地进行数学运算和移动缓冲区。如果输入有效，基本上就能正常运行。大多数可能出错的部分并非发生在 GPU 中（例如网络调用、状态保存和加载等）。因此，有些库期望应用程序开发者做好充分的准备工作，库要么按指示执行，要么就彻底崩溃。"
见 https://www.reddit.com/r/rust/comments/1p67jz5/why_do_so_many_wgpu_functions_panic_on_invalid/
--
From 日报小组 苦瓜小仔
社区学习交流平台订阅：
-
Rustcc论坛: 支持rss
-
微信公众号：Rust语言中文社区