Rust Glancer: Rust LSP usando 100x menos RAM
Um novo servidor de linguagem Rust, o Rust Glancer, pretende reduzir drasticamente o uso de RAM ao transferir a maior parte dos dados de análise para o disco e carregar apenas o necessário para cada consulta, em contraste com o modelo sempre em memória e totalmente incremental do rust-analyzer. Comentários descrevem o rust-analyzer consumindo rotineiramente vários gigabytes de RAM em workspaces grandes e debatem se sua filosofia original de “sem cache em disco, forçar análise rápida” ainda faz sentido à medida que projetos e o uso de proc-macros crescem. A discussão também explora tradeoffs de latência, estratégias de indexação, formatos em disco e suporte futuro a recursos como proc macros e editores adicionais, além de um uso cauteloso, porém pragmático, de LLMs como auxiliares de programação e não como “substitutos do cérebro”.
Objetivos do projeto e arquitetura
- Rust Glancer é um servidor de linguagem Rust que mantém a maior parte dos dados de análise no disco em vez de na RAM.
- Ele faz um índice inicial completo, não incremental, e depois carrega para a memória apenas os dados necessários por consulta.
- Buffers abertos têm prioridade; todo o resto é indexado em segundo plano.
- Ao salvar, ele reindexa apenas o(s) crate(s) afetado(s), não o projeto inteiro; buffers sujos usam uma sobreposição leve de sintaxe sobre o último snapshot semântico.
Uso de memória e tradeoffs de desempenho
- O objetivo é “<100 MB para projetos razoáveis”, embora a indexação inicial possa usar temporariamente mais RAM do que o rust-analyzer (RA).
- O custo de pico é pago principalmente uma vez por projeto ou quando dependências / toolchains mudam.
- Em troca, o uso ocioso é baixo, reinicializações são baratas, e a CPU fica mais fria em comparação com a abordagem incremental sempre ativa do RA.
- Os artefatos em disco escalam com o tamanho do projeto (exemplo dado: ~225 MB para o próprio Rust Glancer).
Cache em disco vs análise incremental em memória
- Vários comentaristas reclamam que o RA pode consumir de vários GiB a dezenas de GiB, especialmente em múltiplos workspaces.
- Alguns argumentam que o RA deveria usar o disco de forma mais agressiva (por exemplo, estruturas mapeadas em memória ou um cache apoiado por RocksDB).
- Uma resposta detalhada explica que o RA evitou deliberadamente o disco no início para:
- Reduzir a complexidade e os problemas de corrupção vistos em caches históricos de IDE.
- Forçar uma análise rápida, preguiçosa, em memória, e bons tempos de inicialização.
- Focar em prototipar a arquitetura de IDE, não em persistência primeiro.
- Um “meio-termo” proposto: índices compactos em disco para dependências mais um backend incremental preguiçoso em memória para o workspace ativo, com a capacidade de alternar quando os arquivos se tornam editáveis.
Proc macros e extensibilidade
- Rust Glancer planeja um modelo de “descreva efeitos, não execute código” para proc macros por meio de um plugin/DSL, visando uma versão futura.
- A motivação é evitar execução arbitrária de código no LSP e ainda assim modelar os efeitos visíveis externamente das macros.
Suporte a editores e UX
- Versões futuras visam oferecer suporte a Neovim e Zed; LSPs ainda precisam de pequenos adaptadores por editor.
- Auto-imports e “find references” são reconhecidos como recursos mais pesados e estão sendo otimizados antes de serem habilitados completamente.
Uso de LLM no desenvolvimento
- O autor trata LLMs como assistentes: bons para conhecimento de domínio, fracos para arquitetura.
- Armadilhas observadas: tendência a inchar o código, duplicar funcionalidades, resistir a refatorações e falar com confiança indevida.
- Outros compartilham tanto experiências positivas (criação rápida de LSPs simples) quanto preocupações com excesso de dependência.
Acrônimos e público
- Há debate sobre se termos como “LSP” deveriam sempre ser expandidos.
- Um lado: sempre explicar acrônimos para ser inclusivo.
- O outro lado: em um fórum focado em programadores, termos como Rust/LSP são assumidos como conhecidos; leitores podem procurá-los se necessário.