Gopls: Дизайн

Контекст

Хотя у Go есть множество отличных и полезных инструментов командной строки, которые улучшают опыт разработки, стало ясно, что интеграция этих инструментов с IDE может вызывать сложности.

Поддержка этих инструментов зависела от добровольности членов сообщества, и они часто несли большую нагрузку по поддержке по мере развития языка, инструментария и среды выполнения. В результате многие инструменты перестали работать, возникли проблемы с поддержкой, появлялись форки и замены, или же предоставляли опыт, который мог быть лучше.

См. раздел ниже о существующих решениях для получения дополнительных проблем и деталей.

Это приемлемо для инструментов, используемых время от времени, но для основных возможностей IDE это неприемлемо.

Автозавершение, переход к определению, форматирование и другие подобные функции должны всегда работать, поскольку они являются ключевыми для разработки на Go.

Команда Go создаст бэкенд редактора, который будет работать в любой системе сборки.

Он также сможет улучшить задержки работы инструментов Go, поскольку каждый инструмент больше не будет отдельно запускать проверку типов при каждом вызове. Вместо этого будет существовать длительно работающий процесс, и данные смогут быть общими между определениями, автозавершением, диагностикой и другими функциями.

Приняв на себя ответственность за эти инструменты и объединив их в виде gopls, команда Go обеспечит, чтобы опыт разработки на Go не был ненужно усложнённым для пользователей Go.

Наличие одного бэкенда редактора упростит жизнь разработчиков Go, команды Go и поддерживаемых плагинов редакторов Go.

См. выступление Ребекки на GopherCon talk и слайды для получения дополнительного контекста.

Нецели

• Скорость командной строки

  Хотя gopls будет иметь режим командной строки, он будет оптимизирован для длительной работы, а не для быстрого отклика, поэтому он может быть не самым подходящим инструментом для таких вещей, как системы CI. Для таких случаев потребуется альтернативный инструмент, использующий те же самые базовые библиотеки для согласованности.

• Среды с низким объёмом памяти

  Чтобы эффективно обрабатывать большие проекты с очень низкой задержкой, gopls будет хранить множество данных в памяти. Предполагается, что разработчики обычно работают на системах с достаточным объёмом оперативной памяти, и это не будет проблемой. В целом это соответствует большому потреблению памяти существующих решений IDE (например, IntelliJ)

• Подсветка синтаксиса

  На данный момент нет редактора, который делегировал бы эту функциональность отдельному двоичному файлу, и нет стандартного способа её реализации.

Существующие решения

Каждый год команда Go проводит опрос, в котором спрашивают разработчиков о их опыте работы с языком.

Одним из вопросов является «Как вы оцениваете свой редактор?».

Ответы рассказали очень негативную историю. Примеры категоризированных цитат:

• Установка
  • «Сложно установить и настроить»
  • «Недостаточная документация»
• Производительность
  • «Производительность очень низкая»
  • «Довольно медленно в больших проектах»
• Надёжность
  • «Функции работают один день, а на следующий перестают»
  • «Инструментарий не обновляется вместе с новыми возможностями языка»

Каждый редактор имеет собственный плагин, который вызывает различные инструменты, многие из которых ломаются при новых релизах Go или потому, что больше не поддерживаются.

Каждый отдельный инструмент должен выполнять работу по пониманию кода и всех его транзитивных зависимостей.

Каждая функция — это отдельный инструмент, с разным набором паттернов для командной строки, разным способом принятия входных данных и разбора вывода, разным способом указания местоположения исходного кода. Чтобы поддерживать существующий набор функций, VSCode установил 24 различных командных инструмента, многие из которых имеют параметры или форки для настройки. При рассмотрении набора инструментов, которые нужно было перенести в модули, во всех редакторах, их оказалось 63 отдельных инструмента.

Все эти инструменты должны понимать код, и они используют одни и те же стандартные библиотеки для этого. Эти библиотеки оптимизированы под такие инструменты, но даже так обработка такого объёма кода занимает много времени. Почти ни один из инструментов не способен возвращать результаты за 100 мс. Пока разработчики печатаются в своём редакторе, активируются несколько из этих функций, что означает, что они не просто платят стоимость один раз, а много раз. В результате общее впечатление от работы в редакторе кажется медлительным, а функции либо не включены, либо иногда выдают результаты настолько медленно, что они становятся бесполезными к моменту их появления. Эта проблема усиливается с увеличением размера кодовой базы, то есть она становится всё хуже со временем, и особенно плохо для крупных кодовых баз, с которыми сталкиваются компании при использовании Go для более важных задач.

Требования

Полный набор функций

Чтобы gopls можно было считать успешным, он должен реализовать полный набор функций, обсужденных ниже. Это набор функций, необходимых пользователям, чтобы чувствовать себя таким же продуктивно, как и раньше, с использованием заменяемого инструментария. Он не включает все функции предыдущих реализаций: некоторые функции почти никогда не используются и должны быть удалены (например, анализ указателей guru), а другие функции не удаётся легко интегрировать и будут решаться обходными путями (замена save hook/linter).

Эквивалентный или лучший опыт

Для всех этих функций пользовательский опыт должен соответствовать или превосходить текущий опыт, доступный во всех редакторах. Это легко сказать, но сложно проверить или измерить. Многие возможные показатели не способны передать опыт.

Например, если была попытка измерить задержку вызова перехода к определению, результаты, скорее всего, были бы довольно стабильными в старом инструменте godef. В реализации gopls же может наблюдаться гораздо более широкий диапазон задержек: лучший случай может быть на порядки быстрее, а худший — лишь немного хуже, поскольку gopls старается выполнять гораздо больше работы, но при этом эффективно кэширует её между вызовами.

Или для вызова автозавершения, оно может быть медленнее, но давать лучшее первое совпадение, что приведёт к тому, что пользователи чаще будут принимать его, в результате чего общее впечатление от использования станет лучше.

В основном всё это должно опираться на отзывы пользователей. Если пользователи отказываются переключаться, потому что опыт не стал лучше, значит, это ещё не сделано. Если же пользователи переходят, но большинство жалуется, то, вероятно, есть достаточно областей, где всё улучшилось, чтобы сделать переход убедительным, но есть и те, где всё хуже. Если же большинство людей переходят и либо молчат, либо остаются довольны, значит, это уже сделано. При создании инструментов, пользователь — это всё.

Надёжное сообщество участников

Объём и масштаб проблемы, которую пытается решить gopls, невозможны для решения командой разработчиков Go в одиночку. Для этого потребуется сильное сообщество, которое сможет реализовать всё это.

Это означает, что код должен быть простым для участия, а также удобным для параллельной работы многих разработчиков. Функциональность должна быть хорошо декомпозирована и иметь полноценную систему тестирования.

Задержки, соответствующие допустимому уровню для пользователя

Существует множество исследований, посвящённых допустимым задержкам для действий пользователя.

Основной вывод, который влияет на gopls, заключается в том, что обратная связь, немедленно реагирующая на непрерывные действия пользователя, должна быть менее 100 мс, чтобы она была незаметной, а всё, что превышает 200 мс, вызывает раздражение у пользователя. Это означает, что в целом цель должна быть установлена на уровне <100 мс для всего, что происходит во время ввода разработчиком. Всегда будут случаи, когда gopls не сможет соответствовать этому сроку, и нужно будет предусмотреть способы сделать пользовательский опыт приемлемым в таких случаях, но в целом цель этого срока — направлять базовый дизайн архитектуры. Любое решение, которое теоретически не сможет соответствовать этой цели в долгосрочной перспективе, является неправильным.

Простота настройки

Разработчики очень требовательны и имеют очень разные предпочтения в своей кодовой среде. gopls должен поддерживать значительную степень гибкости, чтобы удовлетворить эти потребности. Однако, настройки по умолчанию без какой-либо конфигурации должны обеспечивать наилучший опыт для большинства пользователей, и где это возможно, функции должны быть гибкими без необходимости настройки, чтобы клиент мог легко принимать решения о том, как обрабатывать запросы, не меняя способ связи с gopls.

Сложности

Объём данных

• Маленький:
• Средний:
• Большой:
• Корпоративный монорепозиторий: гораздо больше

Анализ и проверка типов большого количества кода довольно затратна, а преобразованные формы занимают много места. Так как gopls должен постоянно обновлять эту информацию во время ввода разработчиком, он должен очень аккуратно управлять кэшированием преобразованных форм, чтобы сбалансировать использование памяти и скорость.

Неверное кэширование

Базовой единицей операции для проверки типов является пакет, но базовой единицей операции для редактора является файл. gopls должен уметь эффективно сопоставлять файлы с пакетами, чтобы при изменении файлов знать, какие пакеты нужно обновить (а также любые другие пакеты, которые зависят от них транзитивно). Это особенно затруднено тем, что изменение содержимого файла может изменить, к каким пакетам он считается принадлежащим (изменяя объявление пакета или build-теги), файл может находиться в нескольких пакетах, а изменения могут быть внесены в файлы без использования редактора, в этом случае редактор не будет уведомлять нас об изменениях.

Неподходящая базовая функциональность

Базовые библиотеки Go (включая go/token, go/ast и go/types) спроектированы для приложений, подобных компилятору. Они больше заботятся о пропускной способности, чем о потреблении памяти, имеют структуры, предназначенные для роста, а затем уничтожения при завершении программы, и не предназначены для работы в случае ошибок в обрабатываемом исходном коде. Также они не имеют возможностей выполнять инкрементальные изменения.

Создание долгосрочной службы, работающей хорошо с этими библиотеками, представляет собой очень большую задачу, но написание новых библиотек потребовало бы гораздо больше усилий и привело бы к значительным долгосрочным затратам, поскольку обе группы библиотек должны были бы поддерживаться. В настоящее время более важно предоставить рабочий инструмент пользователям. В долгосрочной перспективе это решение может потребовать повторного рассмотрения, и новые низкоуровневые библиотеки могут быть единственным способом продолжать продвижение возможностей вперёд.

Возможности системы сборки

gopls должен быть независимым от системы сборки, но он должен использовать систему сборки для выяснения, как файлы сопоставляются с пакетами. При попытке сделать это, даже если функциональность одинакова, затраты (по времени, CPU и памяти) очень различаются и могут значительно повлиять на пользовательский опыт. Разработка того, как gopls взаимодействует с системой сборки, чтобы минимизировать или скрыть эти различия, является сложной задачей.

Build-теги

Система build-тегов в Go довольно мощная и имеет множество вариантов использования. Исходные файлы могут исключать сами себя, используя мощную булеву логику над набором активных тегов. Однако она предназначена для указания набора активных тегов в командной строке, а библиотеки спроектированы так, чтобы справляться только с одной допустимой комбинацией за раз. Также нет способа вычислить набор допустимых комбинаций.

Проверка типов файла требует знания всех других файлов в том же пакете, и этот набор файлов изменяется с помощью build-тегов. Набор экспортируемых идентификаторов пакета также зависит от того, какие файлы входят в пакет, а значит, и от его build-тегов.

Это означает, что даже для файлов или пакетов, у которых нет управления через build-теги, невозможно получить корректные результаты без знания набора build-тегов, которые следует учитывать. Это делает очень трудным получение полезных результатов при просмотре файла.

Возможности, не поддерживаемые LSP

Существуют некоторые вещи, которые было бы хорошо уметь делать, но они не укладываются легко в существующий протокол LSP. Например, отображение информации о потоке управления, автоматические struct-теги, сложные рефакторинги…

Каждая из таких возможностей должна быть тщательно рассмотрена, и либо предложено изменение протокола LSP, либо добавлен способ добавления специфичных для gopls расширений протокола, которые остаются простыми в использовании во всех плагинах редакторов.

Чтобы избежать этого на старте, будут реализованы только основные возможности LSP, поскольку они уже достаточны для выполнения базовых требований, но потенциальные функции должны быть учтены при проектировании основной архитектуры.

Распространение

Обеспечение того, чтобы пользователи использовали правильную версию gopls, станет проблемой. Каждый плагин редактора, вероятно, будет устанавливать инструменты своим способом: некоторые выберут глобальную установку, другие будут хранить свою собственную копию.

Поскольку это новый инструмент, он будет активно развиваться. Если пользователи не будут информированы о том, что они используют устаревшую версию, они столкнутся с проблемами, которые уже были исправлены, что хуже для них, а затем, возможно, будут сообщать об этих проблемах, что будет тратить время у команды gopls. Необходимо создать механизм, позволяющий gopls проверять актуальность версии, а также рекомендовать способ установки актуальной версии.

Отладка проблем пользователей

gopls по сути представляет собой очень состоятельный сервер, работающий на машине разработчика. Его базовая работа затрагивает множество факторов — от среды пользователя до содержимого локального кэша сборки. Данные, над которыми он работает, часто являются конфиденциальными кодовыми базами, которые нельзя делиться.

Все эти обстоятельства делают трудным для пользователей полезное сообщение об ошибке или создание минимального примера воспроизведения.

Нужно обеспечить простые способы для пользователей сообщать доступную информацию, а также способы попытки воспроизведения проблем без использования всего их состояния. Это также необходимо для создания тестов на регрессию.

Основные решения по архитектуре

Существуют некоторые фундаментальные архитектурные решения, которые влияют на большую часть остальной части дизайна инструмента, включая фундаментальные компромиссы, которые влияют на пользовательский опыт.

Время жизни процесса: управляется редактором

Обработка большого кода для полной проверки типов и последующего анализа в рамках требуемых временных рамок невозможна, и это одна из основных проблем существующих решений. Это остается справедливым даже в том случае, если вычисленная информация кэшируется на диске, поскольку запуск анализаторов и проверяющих программ все равно требует полного AST всех файлов в графе зависимостей. Теоретически можно добиться лучшего результата, но только при значительной переработке существующих библиотек парсинга и проверки типов, что в настоящее время невозможно.

Это означает, что gopls должен быть долгоживущим процессом, способным кэшировать и предварительно вычислять результаты в памяти, чтобы при поступлении запроса он мог быстро предоставить ответ.

Он может работать как демон на машине пользователя, но при этом возникает множество проблем с управлением демоном. Возможно, это и правильный выбор в долгосрочной перспективе, и в архитектуре следует учитывать такую возможность, но на начальном этапе будет использоваться процесс, который работает столько же, сколько и редактор, запустивший его, и который может быть легко перезапущен.

Кэширование: в памяти

Постоянные дисковые кэши очень трудно поддерживать и требуют решения множества дополнительных задач. Хотя создание необходимой информации дорогостоящее по сравнению с задержками, необходимыми для обработки запросов, оно довольно незначительно по сравнению со временем запуска редактора, поэтому ожидается, что перестроение информации при перезапуске gopls будет приемлемым.

Преимущество, получаемое от этого, заключается в том, что gopls становится безсостоятельным между перезапусками, то есть если у него возникают проблемы или оно путается в своём состоянии, простой перезапуск часто решает проблему. Это также означает, что при сообщении пользователем о проблемах не требуется вся информация из кэша на диске для диагностики и воспроизведения проблемы.

Обмен данными: stdin/stdout JSON

Спецификация LSP определяет JSON-сообщения, которые обычно используются, но она не определяет, как должны передаваться эти сообщения, и существуют реализации LSP, которые не используют JSON (например, в качестве альтернативы можно использовать Protocol buffers).

Ограничения для gopls заключаются в том, что он должен быть легко интегрируемым в любой редактор на всех операционных системах, и не должен иметь больших внешних зависимостей.

JSON входит в стандартную библиотеку Go и является родным языком LSP, поэтому он наиболее логичен. Безусловно, лучшей поддерживаемой механикой обмена является стандартный ввод и вывод процесса, и все распространённые клиентские реализации имеют способы использования JSON rpc 2 в этом режиме. В Go не было полных реализаций протокола с низкой зависимостью, но он представляет собой довольно простой протокол поверх библиотеки JSON, который можно реализовать с умеренными усилиями и который в любом случае будет полезной библиотекой.

В будущем планируется запускать gopls в отдельном клиент-серверном режиме, поэтому написание его таким образом, чтобы он мог использовать сокеты вместо stdin/stdout с самого начала, было лучшим способом обеспечить возможность такого перехода. Это также оказалось очень полезным при отладке: можно было запускать сервер gopls вручную и отлаживать его вне редактора.

Запуск других инструментов: нет

Возможности

Существует набор возможностей, которые gopls должен предоставлять, чтобы стать полноценным IDE-решением. Ниже приведён минимальный набор возможностей, а также существующие решения и то, как они должны отображаться в LSP.

Инспекция

Возможности инспекции предоставляют разработчикам информацию о коде во время его написания. Они не вносят и не предлагают изменения.

Навигация

Возможности навигации предназначены для того, чтобы облегчить разработчику ориентацию в кодовой базе.

Помощь при редактировании

Эти функции предлагают или применяют правки к коду для пользователя, включая функции рефакторинга, для которых существует множество возможных вариантов использования. Рефакторинг — одно из мест, где инструменты Go могут быть потенциально очень сильными, но до сих пор не были таковыми, и, следовательно, существует огромный потенциал для улучшения пользовательского опыта. Однако пока еще нет четкого понимания того, какие виды рефакторинга нужны пользователям, и как они должны выражаться, а также существуют слабые места в протоколе LSP в этой области. Это означает, что это может быть больше исследовательским проектом.

Исходные файлы этой документации можно найти в golang.org/x/tools/gopls/doc.