采访：David Lattimore – Faster Linker, Faster Builds
David Lattimore 是 Wild Linker 和 Excvr Jupyter 内核的作者。
在访谈中，他介绍了 Wild Linker 的创作初衷，主要是为了在开发过程中提升链接器的速度，以实现像 SmallTalk 那样的即时反馈，让编译语言也能有快速的开发体验。
他分享了自己对 Rust 的热爱，认为 Rust 解决了他在 C 和 C++ 中遇到的诸多问题。
他还指出 Rust 编译器和 Cargo 有改进空间，例如在剥离二进制文件调试信息时，Cargo 会重新构建一切，而实际上只需更改传递给链接器的标志即可。
Wild Linker 仓库：https://github.com/davidlattimore/wild
阅读/收听：https://timclicks.dev/podcast/david-lattimore-faster-linker-faster-builds
Reddit：https://www.reddit.com/r/rust/comments/1l2t9se/audio_interview_about_the_wild_linker_on_compose/
公告：Redox OS 五月进展
Redox OS 是一个用 Rust 编写的类 Unix 微内核操作系统。
5 月亮点包括成功运行 GTK 3 演示，实现了 X11 支持，使 X11 程序无需修改即可在 Redox 上运行。此外，还启用了 Mesa3D EGL，改进了 2D 渲染性能。
系统方面，创建了 /var 目录以符合 Linux FHS 标准，修复了多个内核和驱动问题，包括 ARM64 定时器中断问题。Relibc 和多个程序库也得到了大量更新和修复。
阅读：https://www.redox-os.org/news/this-month-250531/
Reddit：https://www.reddit.com/r/rust/comments/1l3a32m/this_month_in_redox_may_2025/
公告：gccrs 五月进展
Rust-GCC 项目旨在为 GCC 提供一个替代的 Rust 编译器（gccrs）。
5 月的主要工作集中在社区拓展上，包括在 RustWeek 上的演讲，与 Rust-for-Linux 项目团队会面，讨论了 Linux 内核不再依赖 alloc 标准库，这使得 gccrs 更容易编译 core 和内核的 alloc 实现。
项目团队计划在未来 6 个月内完成 GCC 16.1 的第一阶段目标，并开始将内核源码集成到测试基础设施中。
此外，团队还专注于完成 core 的名称解析工作，并修复剩余的宏展开错误。
作为 Google Summer of Code 的一部分，团队将改进模式匹配后端，以支持 core 中的所有模式，并探索 Pin 语义的正确处理。
5 月项目共收到 25 个外部贡献者的拉取请求，并启动了与两位 GSoC 学生的合作。
仓库：https://github.com/Rust-GCC/gccrs
Reddit：https://www.reddit.com/r/rust/comments/1l35el9/gccrs_may_2025_monthly_report/
文章《2,000x faster route propagation by rewriting our Traefik gateway in Rust》
作者：Nathan Flurry
Rivet 是一个开源的自托管无服务器平台，其团队用 Rust 重写了基于 Traefik 的网关，命名为 Rivet Guard。
原 Traefik 网关在路由传播速度和配置响应性上存在瓶颈，导致资源可用性延迟。
Rivet Guard 通过懒加载和缓存路由，将路由传播速度从 2 秒提升到 1 毫秒，支持无限路由，且完全无状态。
它简化了架构，从 3 个组件变为 1 个组件，优化了冷启动，允许资源在客户端连接时启动，并能智能缓冲请求直到资源就绪。Rivet Guard 由 Rust 编写，利用了 Rust 的内存安全性和正确性保证，避免了常见的网络服务问题。
阅读：https://rivet.gg/blog/2025-06-02-faster-route-propagation-by-rewriting-our-traefik-gateway-in-rust
Reddit：https://www.reddit.com/r/rust/comments/1l3479e/2000x_faster_route_propagation_by_rewriting_our/
Egor - 基于 wgpu 的跨平台 2D 图形引擎
我一直用 macroquad 和其他各种 crate（比如三个不同的 ECS）构建一个 MORPG 游戏。
我对 macroquad 的主要不满在于它不是基于 wgpu （wgpu 的编译时间非常快）。另一个让我不满的是，它试图实现 3D 效果，但实际上能力不足。动画、 macroquad-tiled 和 macroquad-platformer 等功能非常不完善，在很多情况下都无法正常工作，对我来说，无论如何都需要重写。
因此，我决定构建一个基于 wgpu 的纯 2D 图形引擎。它类似于 pixels ，无需进行大量优化，但包含纹理、字体等功能。
我构建 egor 目的是使其更通用，而不是只针对特定游戏。目前，我有两个简单的演示，展示了精灵动画之类的功能（并非 egor 的抽象），并且我计划添加一些与游戏无关的演示。
它旨在成为一种构建 GUI 应用程序的方法，其中包含计时、输入、渲染/字体等基本功能。
仓库：https://github.com/wick3dr0se/egor
Reddit：https://www.reddit.com/r/rust/comments/1l38pyw/egor_crossplatform_2d_graphics_engine/
讨论：为什么 Rust 还没有合适的 GUI 生态系统？
一些高赞回答：
- “GUI 很难。很多人开始一个项目，然后开始编写自己的标签和按钮实现，就以为快完成了。然后他们尝试处理文本字段，但大多数时候都没有任何消息。”
- “然后是字体渲染，几乎每个操作系统/设备都使用相同的库。你知道吗，字体可以包含一个执行的微型状态机？”
- “字体可以包含字节码程序，这些程序必须被执行才能计算正确的提示 。此外，还有 OpenType 的特性， 比如任意上下文相关的重写规则（所以，状态机在这里是不够的，你需要一个线性有界自动机……）。”
Reddit：https://www.reddit.com/r/rust/comments/1l303wm/why_doesnt_rust_have_a_proper_gui_ecosystem_yet/
--
From 日报小组 苦瓜小仔
社区学习交流平台订阅：
评论区
写评论还没有评论