Rust Glancer: новый Rust LSP обещает в 100 раз меньше памяти, чем rust-analyzer

Автор четыре месяца разрабатывал Rust Glancer, альтернативу стандартному языковому серверу rust-analyzer (LSP, Language Server Protocol, модуль, который даёт редактору автодополнение, переход к определению и подобные функции). Главная цель проекта, низкое потребление памяти: цель разработчика, уложиться в менее 100 МБ ОЗУ на разумных по размеру проектах (с оговорками, которые в тексте отдельно не расписаны), и в демонстрационном видео потребление всё время оставалось ниже 100 МБ. Вторая особенность, мгновенная готовность после перезапуска редактора: если проект уже был проиндексирован раньше, переиндексация при перезапуске не требуется.

Автор пишет, что rust-analyzer тратит много памяти по трём причинам: рабочие пространства Rust содержат огромный объём связанной информации (функции, структуры, трейты, их связи), которую нужно хранить целиком; rust-analyzer использует инкрементальную базу данных salsa, которая по своей природе привязана к памяти; и структуру дерева синтаксиса rowan, которая ускоряет частичный разбор при каждом нажатии клавиши, но вызывает сильную фрагментацию памяти. Идея Rust Glancer, отказаться от инкрементальности: анализ выполняется целиком, результат замораживается и сохраняется на диске, а в память подгружается только то, что нужно для конкретного запроса. Это медленнее, чем схема rust-analyzer, поэтому Glancer использует компромиссы: при наборе текста не выполняется полный анализ на каждое нажатие клавиши, а используется поверхностный разбор текущего тела функции поверх ранее сохранённого полного индекса, из-за этого новые элементы (импорты, структуры, трейты) не попадают в индекс до сохранения файла.

Отдельно автор отмечает, что Rust Glancer настроен на работу с ИИ-агентами, которые правят код вне редактора: у него был замечен эффект, при котором подсказки (inlay hints) в rust-analyzer съезжали после таких правок, и та же проблема поначалу была в Glancer, её решили собственным файловым наблюдателем и понижением приоритета обработки правок, сделанных вне редактора, чтобы они не вызывали немедленную повторную индексацию всего проекта.

Личный повод для проекта: автор пишет на Rust профессионально около 7 лет, вносил правки в rustc, clippy и rust-analyzer, но у него нестандартный рабочий процесс, два одинаковых окна редактора на двух мониторах с одними и теми же проектами, из-за чего потребление памяти удваивается (он оценивает это как «примерно 2N»); на последнем наборе проектов rust-analyzer доходил до 16 ГБ. Автор тестировал Glancer на старом MacBook Pro M1 2020 с 8 ГБ ОЗУ и остался доволен результатом; около полутора месяцев назад он перешёл на Glancer как на основной инструмент.

Технически проект прошёл путь от «умного ctags для Rust» до почти полноценного LSP: индексация деклараций, затем упрощённый вывод типов, затем, после того как понадобилось поддержать обычный код с срезами, замыканиями и трейтами, полноценный движок вывода типов и интеграция решателя трейтов Chalk (взят из экосистемы rust-analyzer). Сейчас Glancer поддерживает индексацию с выводом типов, раскрытие декларативных макросов, и большинство типовых действий LSP: переход к определению, всплывающие подсказки, inlay hints, автодополнение. Проект пока неполный: в нём много недостающей функциональности и известных багов, и сам автор пишет, что маловероятно, что Glancer когда-либо станет «таким же, как rust-analyzer, но лучше», он видит его нишей для слабых машин и для тех, кто готов на компромиссы ради экономии памяти, тогда как rust-analyzer, по его же мнению, останется выбором по умолчанию для проектов, где важны полнота и точность при каждом нажатии клавиши.

Проект активно писался с помощью LLM, но, по словам автора, это не «вайб-кодинг» (написание кода под диктовку ИИ без проверки): он утверждает, что проверяет каждый pull request и следит за состоянием кодовой базы, ссылаясь на то, что в истории git есть PR с более чем 10 тысячами строк изменений, сделанные с промежутком в несколько дней, а не за один присест. Он описывает повторяющийся цикл работы с LLM: предложение модели выглядит разумным, он его принимает, что-то начинает беспокоить, он обдумывает архитектуру, находит изъян и вместе с LLM его исправляет. Попробовать Rust Glancer уже можно, доступно расширение для VS Code, либо можно собрать vsix-файл из репозитория проекта.

Ключевые факты

• Rust Glancer, альтернативный языковой сервер (LSP) для Rust; разработка идёт 4 месяца, цель, уложиться в менее 100 МБ ОЗУ на обычных проектах.
• Вместо инкрементального анализа в памяти (как у rust-analyzer) Glancer выполняет анализ целиком и сохраняет результат на диске, это позволяет не переиндексировать проект при перезапуске редактора.
• Автор описывает свой личный кейс: на двух одновременно открытых окнах с одинаковыми проектами rust-analyzer доходил до 16 ГБ памяти; тестировал Glancer на MacBook Pro M1 2020 с 8 ГБ ОЗУ.
• Плата за экономию памяти, задержка индексации новых элементов (импортов, структур, трейтов) до сохранения файла, и в целом более медленный отклик, чем у rust-analyzer.
• Проект написан с большим участием LLM, но, по словам автора, каждый pull request проверяется вручную; уже доступен как расширение VS Code.

Почему это важно

Высокое потребление памяти rust-analyzer, известная и часто обсуждаемая проблема Rust-тулинга, особенно на слабых машинах или при работе с несколькими проектами одновременно. Rust Glancer предлагает конкретную архитектурную альтернативу: не держать весь анализ проекта в памяти, а выгружать результат на диск и подгружать по требованию. Это не абстрактная идея, а рабочий прототип с полноценным выводом типов, решателем трейтов и поддержкой типовых действий LSP (переход к определению, автодополнение, inlay hints), доступный для установки уже сейчас.

Кому это важно

В первую очередь, Rust-разработчикам на старых или маломощных машинах: автор сам тестировал проект на MacBook Pro M1 2020 с 8 ГБ ОЗУ. Также, тем, кто держит открытыми сразу несколько инстансов редактора с одинаковыми проектами (у автора именно такой рабочий процесс, и rust-analyzer у него доходил до 16 ГБ). Отдельно автор упоминает пользователей агентных рабочих процессов: Glancer специально настроен так, чтобы правки кода вне редактора со стороны ИИ-агентов не вызывали немедленную полную переиндексацию.

Как это применить

Rust Glancer уже можно попробовать: доступно расширение для VS Code, либо можно собрать и установить vsix-файл из репозитория проекта. Стоит понимать компромисс: новые элементы (импорты, структуры, трейты) не индексируются, пока файл не сохранён, а полный анализ выполняется не на каждое нажатие клавиши, а только при сохранении, поверх него используется упрощённый разбор текущей функции. Автор прямо пишет, что rust-analyzer, по его мнению, останется выбором по умолчанию там, где важны полнота и точность в реальном времени, а Glancer подходит тем, кто готов пожертвовать этим ради экономии памяти.

Можно ли доверять

Источник, личный пост автора проекта на его блоге, кросс-постнутый на Hacker News (109 баллов, 31 комментарий на момент публикации пересказа). Изложение идёт от первого лица, включает подробное техническое объяснение архитектурных решений и историю разработки. Цифра «в 100 раз меньше памяти» взята из заголовка исходного поста, в самом тексте нет отдельного прямого замера рядом с rust-analyzer, только личный кейс автора (16 ГБ на двух окнах против цели «менее 100 МБ» у Glancer) и демонстрационное видео, где потребление держалось ниже 100 МБ. Независимого стороннего бенчмарка в тексте нет.

Риски и подводные камни

Проект молодой (4 месяца разработки) и, по собственному признанию автора, далёк от завершённости: не хватает функциональности, есть известные баги. Экономия памяти достигается за счёт задержки индексации до сохранения файла и в целом более медленного отклика, чем у инкрементального rust-analyzer, для части сценариев это может ощущаться как менее отзывчивый редактор. Автор сам не ожидает, что Glancer догонит rust-analyzer по полноте и точности. Проект писался с большим участием LLM; автор утверждает, что проверяет каждый pull request, но это утверждение не подкреплено в тексте ничем, кроме его собственных слов и ссылки на объём отдельных PR.

«Это не вайб-кодинг (написание кода под диктовку ИИ без проверки): я проверяю каждый pull request, чтобы быть уверенным в состоянии кодовой базы.»

— автор проекта Rust Glancer