我从不墨守成规
- Electron 慢，我用 GPUI 重写。
- GPUI 缺基础，那我就打基础。
- GPUI 的 CPU 开销大，Zed推进慢，我就用 GPUI Fast 解决它。
- GPUI 无法覆盖移动端、Web，我就搞 NSH。
- Rust 编译慢、占用磁盘，我就改造它。
束缚你的是勇气与魄力！
显示更多
Discord 终于也用 GPUI 重写客户端了，之前都是 Electron。
早该这么干了，下一个是 Slack。
上个月我还在抱怨 Rust 磁盘占用，每天都要清理。
今天这已经不再是一个问题，我的电脑打满了 worktree，自动化 AI 开发。但我根本没遇到磁盘问题了，今天是第 5 天。
由于不再删除 target，就不会全新编译，电脑也不卡了。
放心搞 Rust，直接安装我这个 huacnlee/cargo。
截图是我的 Omarchy 和 Mac，基本上每个项目能有效控制在 20G 左右。
We can fix everything!
显示更多
Rust 的 target 目录就如同 node_modules 一般让人讨厌。
占用空间也就算了，还分散在各个项目里面，清理得一个一个找。
我 fork 一个 cargo 把 target 强制放一起，并且跟 worktree 强制共享，这样能有效减少空间占用，也能提升编译速度。
初步有效果。我还在尝试优化，今天上午到现在，我已经没担心磁盘问题了。
显示更多
你可能无需在意 Rust 编译速度和 target 对磁盘占用的问题。
因为 GPUI Shell 提供的能力，你可能都不需要用 Rust 来开发 GPUI 应用了，直接 JS 就了，不编译才是最快的。
它依然能获得匹配 Rust 版本 GPUI 的性能，以及绝大多数能力，目前看能适应非常应用开发场景了。
我已经用 GPUI Shell 尝试开发各种各样的应用来验证它的实力。
视频中的 case，仅仅给一张参考图，用来测试 AI 基于它 + GPUI Shell 实现完成一个应用。
显示更多
Rust 的编译速度和构建产物占用，已成为 AI 时代的严重瓶颈。
多个 agents 并行、多 worktree，反复 build 和 check，再强的 CPU 也经常被打满，一个个几十 G 起步的 target 一点一点吃掉磁盘空间（并且今年 SSD 还那么贵）。
AI 写代码越来越快，构建成本越来越显眼。
如果有一门能有 Go 一样的编译速度，又有 Rust 那样无 GC、内存安全，以及深入底层做极致性能优化的能力，那将是最适合 AI 时代的编程语言。
显示更多
很快 GitHub 上 PR Review 将是一个难题。已经看到 Omarchy 之类的很多项目积累了很多 PR 了。
Vibe coding 的时候，应该避免给 AI（SI）加各类约束，比如用什么框架、数据库、前端组件、存储用什么等等。
我们应该像个老板安排目标一样来做，而不是指挥说必须这个，必须那个。应该给你的下属（agents）开放命题，让他们提出方案，然后你来决定。
否则你会成为整个项目的上限。
显示更多
