alt-tabr 闲置能耗比 AltTab 低 146 倍
alt-tabr 是 macOS 上的窗口切换器，用 Rust 和原生 AppKit 写成。作者 bl1ndguy0 2026 年 11 月 2 日发到 r/rust，采集时 0 分、6 条评论。站点是 https://alt-tabr.com/。
帖子写，它挂在 MacBook 的刘海上，用来替换系统的 ⌘Tab。实现是原生 AppKit，没有 Electron，也没有额外运行时。作者给出的闲置能耗数字是：在 M1 Pro 上，比 AltTab 低 146 倍。内置 3 套主题，其中 Carousel 会绕着刘海排窗口。快捷键可以把窗口最大化，或贴到半屏。选项可以写进 dotfiles，再从里面恢复。更新在应用内安装。帖子写没有遥测，权限只申请了辅助功能（Accessibility）。
价格写的是前 300 名 9 美元，之后 29 美元。一次购买覆盖 3 台 Mac，含后续更新，30 天内可退款。
作者在评论里写，系统自带的 ⌘Tab 切到一个应用时，最小化的窗口还留在 Dock 里，屏幕上可能没有窗口。alt-tabr 会列出每个窗口，包括最小化的，选中后打开那个窗口。有条评论引用了“内存少 12 倍”。作者回复，这个对比只针对 AltTab。
原文链接：https://www.reddit.com/r/rust/comments/1xlkt36/i_made_a_tab_replacement_that_hangs_from_the/
结构体字段简写想吃掉 .into()
这篇帖子讨论怎么扩展 Rust 的字段初始化简写。作者 dgkimpton 2026 年 11 月 1 日发到 r/rust，采集时 21 分、20 条评论。
现在可以写 Data { variable }，不必再写 Data { variable: variable }。作者希望同名时再往前走一步，例如 Data { variable.into() } 和 Data { &variable }，字段名不用再写一遍。作者写，编译器已经从结构体定义知道字段名和目标类型，类型推断不会因此改变。
Haunting_Rise_8754 的评论有 40 分。评论写，现有简写是字段名和值一一对应；字段位置再放方法调用会更难读，尤其是 .into()。作者回复，只取第一个词：Data { variable.something().field.that() } 填的是 variable 字段。作者又写，只允许一个 .，覆盖 .into()、.as_ref() 这类写法，就能处理他所说的 99% 情况。
ROBOTRON31415 的评论有 22 分。评论举了 Data { composite.variable() }。它可以理解成 variable: composite.variable()，也可以理解成按字段名调用方法，两种读法分不清。评论写，现有规则够用；再加特例会让这套语法更难完整理解，并拿生命周期省略规则做对照。作者回复，按第一个词来可以覆盖他说的 90%，剩下的仍显式写出字段名。如果不这样，几乎总会填到名为 into 的字段。
原文链接：https://www.reddit.com/r/rust/comments/1xl66nq/extended_field_init_shorthand/
测试配置用 opt-level = 1
这篇帖子比较 Cargo 测试配置里的优化级别。作者 Iurigrang 2026 年 11 月 1 日发到 r/rust，采集时 7 分、9 条评论。
作者引用的常见建议是：
[profile.test]
inherits = "release"
debug = "line-tables-only"
作者在自己的小项目里改成：
[profile.test]
opt-level = 1
作者写，在这些项目里，opt-level = 1 让编译时间大约多 20%，测试经常快几倍。继承 release 的那组配置，编译时间大约慢 4 倍，运行时间往往只快几个百分点。这组对比还没把调试符号算进去。
评论里有人写，嵌入式设备的闪存很小。opt-level = 0 的二进制比 opt-level = 1 大很多，因为 0 不会尽量静态消掉 panic 分支，结果放不进 flash。作者回复，自己的项目里二进制大小差别不大。另一条评论问 opt-level = "s" 和 "z"。blockMath_2048 写，s 和 z 基本上是 O3，优化指标换成体积，帮不上编译时间。nicoburns 写，自己的 GUI 项目做交互测试时需要 O3；构建缓存是热的时候，release 增量编译也不算慢，只编一份 O3 还能少占磁盘。
原文链接：https://www.reddit.com/r/rust/comments/1xlhydt/i_dont_see_enough_people_talking_about_optlevel_1/
Git Bonsai 按提交记录长像素盆景
Git Bonsai 是一个 GitHub Action，单个 Rust 二进制，按提交记录在个人主页 README 里长出一棵像素盆景。作者 Just_Stuff_AI 2026 年 11 月 1 日发到 r/rust，采集时 0 分、2 条评论。仓库是 appnice/git-bonsai，许可证 MIT。
每个有提交的仓库长成一根枝，语言决定叶子颜色。归档的仓库会被剪掉，并留下疤。连续提交 21 天会开花。安静两个月会休眠。状态写在仓库里的 bonsai/state.json。每次运行只补缺失的日期。第一次运行会重放全部历史，老账号一开始就是一棵长大的树。
随机数用 ChaCha8，种子是登录名加元素名。不用 HashMap 的迭代顺序，容器用 BTreeMap。同一份状态打出同一串字节，golden test 钉住每个像素。SVG 不靠图像库：每个树格子写一个 rect，空白日期共用一个 <use>，生长动画用 CSS keyframes。帖子写 SVG 大约 70 KB，并认 prefers-reduced-motion。GIF 导出走手写的光栅器，帧用差分矩形。颜色在 OKLCH 里，每种 Linguist 颜色做四档深浅，明度拉开，两种主题下叶子都看得清。proptest 摆了 1000 棵随机树，检查垫片不重叠。每根枝每天最多长一格，尺寸按 log2(commits) 走。
评论指出提交记录里有 Claude 共同作者。作者回复，by hand 指的是 SVG 不靠图像库，共同作者没有藏。
原文链接：https://github.com/appnice/git-bonsai
From Rust中文社区 Mike
社区学习交流平台订阅：
评论区
写评论还没有评论