一个人,四个月,写出了一个能跟rust-analyzer掰手腕的Rust语言服务器——这事本身就有点反常。更反常的是它的卖点:不是更快、更全,而是更省内存,目标是把合理项目的占用压到100MB以下。
这个项目叫Rust Glancer,作者是个写了七年Rust的工程师,给rust-analyzer贡献过代码,也吃够了它的内存苦头。故事的起点很朴素:他习惯两块屏幕各开一个IDE,同一批项目开两份,rust-analyzer的内存占用直接翻倍,自述达到过16GB,风扇狂转。这不是普遍基准测试,是他自己的工作流写照,但足够说明问题出在哪。
发生了什么
- 是什么.一款独立开发的Rust LSP,已上线VS Code插件,可试用。
- 核心卖点.内存目标低于100MB(限"合理项目"),重启编辑器不用重新索引。
- 实测环境.作者称在8GB内存的2020款M1 MacBook Pro上日常使用,体验尚可。
- 完成度.已有完整索引流程、类型推断、trait求解(基于Chalk),支持跳转定义、悬浮提示、补全等常规LSP功能,但功能不全,有已知bug。
- 开发方式.大量借助LLM辅助编码,作者称每一次提交都亲自审核,不是"vibe coding"。
这几条信息,决定了它现在是什么、不是什么:一个可用但不完整的替代品,不是rust-analyzer的平替。
省下的内存,是怎么省出来的
rust-analyzer内存大,不是设计失误,是权衡的结果。它用salsa做增量查询数据库,靠懒计算避免重复劳动,但数据必须常驻内存;用rowan做语法树,支持局部重解析,代价是树状结构容易造成内存碎片。这两个选择让rust-analyzer反应快,也让它变重。
Rust Glancer反过来想:如果放弃"实时增量",只保留一份冻结的分析结果,会怎样?结果可以存进文件系统,查询时才加载进内存;重启编辑器时,索引已经在磁盘上,不用重新跑一遍。
代价也很直接:敲键盘时,它不做全量分析,只对当前函数体做浅层分析,复用上一次完整索引;新写的导入、结构体、trait要等保存后才真正进入索引。作者说习惯了不觉得别扭,但这确实意味着实时准确性打了折扣。
- 风险.保存前的新代码在编辑器里"看不见",代理式编辑(agent大批量改代码)场景下更依赖文件监听机制去补偿。
作者给出的索引速度对比,是他自己在两台机器上的实测,不是行业基准:
| 机器/引擎 | 基础索引可用 | 完整索引 |
|---|---|---|
| M4 Max 36GB / Rust Glancer | 5秒 | 8秒 |
| M4 Max 36GB / rust-analyzer | 6秒 | 13秒 |
| M1 8GB / Rust Glancer | 6秒 | 9秒 |
| M1 8GB / rust-analyzer | 7秒 | 14秒 |
数字看着漂亮,但样本只有一个项目、两台机器,不能当成Rust Glancer普遍更快的证据,只能说明:在他测的场景里,冻结索引没有拖慢启动,反而因为省去内存管理开销跑得更快。
我更在意的不是这几秒钟的快慢,而是这个项目暴露出的一个事实:rust-analyzer好用,但对硬件是有门槛的。8GB内存的机器、老款笔记本、云端轻量开发环境,这些场景里,一个"功能打折但能跑起来"的LSP,比一个"功能齐全但吃光内存"的LSP更有用。
孔子说"过犹不及",工具也一样。rust-analyzer把增量分析和语法树设计做到了极致,换来了极佳的实时体验,但也把内存开销推到了普通笔记本吃不消的地步。Rust Glancer反其道而行,牺牲一部分实时性和完整性,把门槛拉回到弱机器能够着的地方。这不是谁更先进,是两种不同处境下的两种解法。
它现在还有明显短板:代理式AI编辑时容易出现提示信息错位,proc macro和build script支持缺失,作者也明确说不打算支持需要执行不受信任代码的proc macro方案。用LLM辅助开发这件事本身不是减分项也不是加分项——项目质量最终看的是代码能不能跑、bug多不多,不是看谁写的。
- 建议.如果你在用低配设备写Rust,或者能接受保存后才更新索引,可以试试;如果你依赖实时的敲键级准确性,rust-analyzer目前仍是更稳的选择。
真正值得盯的变量,是proc macro支持能不能补上、内存碎片问题能不能进一步压缩。这两点解决之前,Rust Glancer都只是一个"够用"的备选项,不是终局答案。