Rust Glancer: Rust LSP usando 100x menos RAM

Artículo original ↗ Discusión en Hacker News ↗

Un nuevo servidor de lenguaje para Rust, Rust Glancer, busca reducir drásticamente el uso de RAM trasladando la mayor parte de los datos de análisis al disco y cargando solo lo necesario para cada consulta, en contraste con el modelo siempre en memoria y totalmente incremental de rust-analyzer. Los comentaristas describen que rust-analyzer consume con frecuencia varios gigabytes de RAM en workspaces grandes y debaten si su filosofía original de “sin caché en disco, forzar análisis rápido” sigue teniendo sentido a medida que crecen los proyectos y el uso de proc-macros. El hilo también explora compensaciones en latencia, estrategias de indexación, formatos en disco y soporte futuro para funciones como proc macros y editores adicionales, además de un uso cauteloso pero pragmático de LLMs como ayudas de programación y no como “sustitutos del cerebro”.

Objetivos y arquitectura del proyecto

  • Rust Glancer es un servidor de lenguaje para Rust que mantiene la mayor parte de los datos de análisis en disco en lugar de en RAM.
  • Realiza un índice inicial completo, no incremental, y luego carga en memoria solo los datos necesarios para cada consulta.
  • Se da prioridad a los búferes abiertos; todo lo demás se indexa en segundo plano.
  • Al guardar, reindexa solo el/los crate(s) afectados, no todo el proyecto; los búferes sucios usan una superposición sintáctica ligera sobre la última instantánea semántica.

Uso de memoria y compromisos de rendimiento

  • El objetivo es “<100 MB para proyectos razonables”, aunque la indexación inicial puede usar brevemente más RAM que rust-analyzer (RA).
  • El coste máximo se paga en gran parte una vez por proyecto o cuando cambian las dependencias / toolchains.
  • A cambio, el uso en reposo es bajo, los reinicios son baratos y la CPU se mantiene más fría en comparación con el enfoque incremental siempre activo de RA.
  • Los artefactos en disco escalan con el tamaño del proyecto (se da como ejemplo ~225 MB para el propio Rust Glancer).

Caché en disco frente a análisis incremental en memoria

  • Varios comentaristas se quejan de que RA puede consumir varios GiB hasta decenas de GiB, especialmente en múltiples workspaces.
  • Algunos sostienen que RA debería usar más agresivamente el disco (por ejemplo, estructuras mapeadas en memoria o una caché respaldada por RocksDB).
  • Una respuesta detallada explica que RA evitó deliberadamente el disco al principio para:
    • Reducir la complejidad y los problemas de corrupción vistos en cachés históricas de IDE.
    • Forzar un análisis rápido, diferido, en memoria, y buenos tiempos de arranque.
    • Centrarse en prototipar la arquitectura del IDE, no en la persistencia primero.
  • “Punto intermedio” propuesto: índices compactos en disco para dependencias más un backend incremental diferido en memoria para el workspace activo, con la capacidad de cambiar cuando los archivos se vuelvan editables.

Proc macros y extensibilidad

  • Rust Glancer planea un modelo de “describir efectos, no ejecutar código” para proc macros mediante un plugin/DSL, apuntando a una versión futura.
  • La motivación es evitar la ejecución arbitraria de código en el LSP y, aun así, modelar los efectos visibles externamente de las macros.

Compatibilidad con editores y UX

  • Las próximas versiones pretenden dar soporte a Neovim y Zed; los LSP aún necesitan pequeños adaptadores por editor.
  • Los auto-imports y “find references” se reconocen como funciones más pesadas y se están optimizando antes de habilitarlas por completo.

Uso de LLMs en el desarrollo

  • El autor trata a los LLMs como asistentes: buenos para conocimiento del dominio, débiles para la arquitectura.
  • Se señalan problemas: tendencia a inflar código, duplicar funcionalidad, resistirse a refactors y hablar con una confianza injustificada.
  • Otros comparten tanto experiencias positivas (crear rápidamente LSPs simples) como preocupaciones por la sobredependencia.

Acrónimos y audiencia

  • Hay debate sobre si términos como “LSP” siempre deben expandirse.
  • Un lado: explicar siempre los acrónimos para ser inclusivos.
  • El otro lado: en un foro centrado en programadores, se asume que términos como Rust/LSP se conocen; si hace falta, los lectores pueden buscarlos.