В настоящее время у нас есть этот прекрасный момент в году, когда все пишут, пишут в Твиттере и инстаграмм о своих достижениях в прошлом году и планах на следующий. Я тоже делал это раньше (часто с опозданием на неделю… или месяц), однако в этом году я решил написать о другом. Итак, давайте поговорим о кроссплатформенных инструментах редактора F #, управляемом сообществом.
Протокол языкового сервера
Прежде чем углубиться в конкретные вещи F #, я должен упомянуть проект, который изменил способ построения инструментов редактора за последние два года - Протокол языкового сервера (LSP). LSP - это спецификация связи между клиентом (редактором) и сервером, которая предоставляет возможности языковых инструментов, такие как автозаполнение, всплывающие подсказки и т. Д. Это сокращает проблему m-times-n до m -plus-n проблема - аналогично тому, как виртуальные машины решают ту же проблему для развертывания кода на многих платформах (отличный пример - Z-машина).
Например, вместо создания плагина Python VSCode, плагина Python vim, плагина Python Atom и плагинов Python для любых других потенциальных клиентов он позволяет разработчикам сосредоточиться на одной реализации языкового сервера, это будет автоматически поддерживаться всеми клиентами. которые реализуют LSP.
Конечно, идея языкового сервера не нова - это довольно распространенный способ создания языковых инструментов. Фактически, в языке F # уже есть языковая служба под названием F # Compiler Service. Это F # API внутри компилятора F #, который берет на себя всю тяжелую работу по определению вещей, полезных для инструментов редактора. Однако в конечном итоге это просто F # (т.е. .NET) API, который нельзя использовать в любой среде без дополнительного интерфейса. Дополнительный уровень, который может взаимодействовать между службой компилятора F # и любым редактором (т. Е. Не только Visual Studio), необходим для того, чтобы инструменты F # можно было использовать повсюду.
FsAutoComplete
Как я уже упоминал, идея языкового сервера не нова. И у F # он есть уже много лет. Первоначально созданный в 2011 году (насколько я знаю, это было задолго до того, как я присоединился к сообществу F #), FsAutoComplete (FSAC) использовался всеми редакторами, не относящимися к Visual Studio, такими как Atom, Emacs, Vim, и VSCode. Проект предоставляет высокоуровневый API через службы компилятора F # и уровень связи (стандартный ввод-вывод и веб-сервер HTTP), который позволяет использовать его с платформ, отличных от .NET. Это давний проект с множеством прошлых итераций - на самом деле, до того, как API службы компилятора F # стал доступным, он использовал отражение над компилятором F # для доступа к внутренним API! За эти годы у него было много отличных сопровождающих и участников (особенно нужно упомянуть здесь Дэйва Томаса, Робина Незервея, Томаса Петричека и Энрико Сада), и именно магия питает Ionide с дня-0.
Текущий статус
Когда я начал Ionide 4 года назад, FSAC был в довольно хорошей форме, предоставляя множество важных API и один коммуникационный уровень (stdio). С годами я начал вносить все больший и больший вклад в проект, и с помощью всех участвующих замечательных людей, новых участников и поддержки сообщества нам удалось превратить FSAC в один из лучших языковых серверов, которые я знаю (особенно учитывая, что это не коммерческая языковая служба, например, созданная Microsoft или JetBrains), и я считаю, что это был один из самых важных инструментов, созданных сообществом .NET OSS.
Также лично для меня важен уровень инноваций, которого нам удалось достичь в FSAC и Ionide. Дополнительная диагностика, такая как неиспользуемые открытия или неиспользуемые привязки, интеграция со сторонним линтером, функции, обеспечивающие работу CodeLenses Ionide, фоновое кэширование, которое позволяет очень быстро использовать любую функцию, требующую символов (например, Find References, CodeLens, показывающую количество ссылок и т. Д.) , и даже кастомные F # Analyzers. Это не те функции, которые вы обычно видите в инструментах редактора, созданных независимыми поставщиками, и особенно в инструментах редактора для языков FP (да, некоторые из этих функций присутствовали в мощных IDE для определенных языков - CodeLenses для C # в VS или известные фоновые кэши в IDE JetBrains - но никогда для языков программирования FP и никогда не предоставляются инструментами сообщества)
Светлое будущее?
Итак, заголовок поста обещал говорить о будущем… но будущее уже наступило. Сегодня я хотел бы показать вам то, над чем я работал во время рождественских каникул последние две недели - коммуникационный уровень LSP для FSAC.
Огромное спасибо Жюльену Ронкаглиа за его первоначальную работу над доказательством концепции LSP + FSAC несколько месяцев назад и его реализацию абстракции сервера F # LSP, которая была использована в качестве основы для моей текущей работы.
Поскольку я являюсь активным сопровождающим инструментов редактора для двух разных языков, разработчиком, создавшим плагины для нескольких редакторов, и тем, кто в целом интересуется инструментами редактора, для меня стало очевидным, что LSP победил (по крайней мере, в своей нише). кроссплатформенных инструментов, предоставляемых сообществом / независимыми поставщиками). Появляется все больше и больше клиентских реализаций (включая действительно интересные онлайн-среды IDE, такие как GitPod), все больше и больше серверных реализаций (что означает все больше и больше инвестиций в клиентов), а сам протокол становится все более мощным и функциональным. Я твердо верю, что это будущее кроссплатформенного инструментария F #. С точки зрения F # есть несколько важных преимуществ:
- Он перемещает много кода из базы кода Ionide в базу кода FSAC - это означает, что другие редакторы, кроме VSCode, могут использовать некоторые из улучшений, которые были «взломаны» в самом Ionide.
- Это упрощает процесс добавления - Ionide - это плагин VSCode, написанный на F #, скомпилированный в JS с Fable с использованием FSAC (полностью отдельная кодовая база). Это делает процесс участия немного неудобным - если вы хотите внести свой вклад, вам нужно знать, с какой базой кода работать, если это Ionide, вам нужно настроить набор инструментов Fable. Идея использования F # для Ionide заключалась в том, чтобы снизить планку для участников (люди, заинтересованные в улучшении инструментов F #, являются разработчиками F #, поэтому код должен быть F #). Поскольку много кода Ionide перемещается в FSAC, это еще больше упрощает внесение изменений, перемещая большой объем кода в обычный проект F # /. NET Core.
- Это хорошая новость для всех, кто хочет использовать Atom, Vim или Emacs (или, может быть, ST3?) - некоторые из этих плагинов не поддерживаются очень активно (или устарели, как Ionide-Atom), но переход на LSP будет означать, что все новые модные функции должны быть проще или «бесплатными».
- Вскоре я начну работу над выпуском Ionide 3.0, который будет основан на LSP. Много кода Ionide будет удалено, поскольку Ionide предоставляет больше функциональных возможностей, чем просто языковые функции - такие вещи, как обозреватель решений, создание новых проектов, щелчок правой кнопкой мыши - ›отладка, и многие функции, ориентированные на взаимодействие с разработчиками, являются реализациями, специфичными для VSCode (и, вероятно, Так как FSAC возьмет на себя множество обязанностей, я надеюсь сосредоточиться больше на UX в самом Ionide, что само по себе является очень интересной проблемой.
В качестве примечания - мы ищем новых сопровождающих для FSAC. Мы будем рады вашей помощи!
Мрачное будущее?
Конечно, в каждой реальной истории есть и плохие стороны. И на горизонте пара темных облаков. Во-первых, некоторые из проблем с Ionide / FSAC не исчезнут с переходом на LSP - они связаны со сложностью сборки и требуют больше знаний и времени, чем у меня (если кто-то от MSFT - я хотел бы получить на поздний рождественский подарок открытый кроссплатформенный языковой сервер для системы проектов .Net). Но это чисто техническая проблема. Более того, за последний год ничего не изменилось, и я могу повторить свои слова из прошлогодней публикации. Хотя я считаю, что экосистема F # находится в лучшей форме, она все еще строит замок на песке - недостаточно участников, в зависимости от той же горстки людей, которые производят перепроизводство, нет коммерческой поддержки проектов OSS, нет компаний, заинтересованных в инвестировании в F # OSS. экосистема. И Ionide, и FSAC находятся в неустойчивом состоянии - критически важные проекты для сообщества F # с тысячами пользователей, которые используются огромной частью сообщества каждый день - они не получают коммерческой поддержки и недостаточно участников, чтобы компенсировать это.
So… 2019?
Итак, как будет выглядеть 2019 год? Время покажет. Но в целом я считаю, что светлых сторон в этой истории больше, чем темных туч. Экосистема F # находится в довольно хорошем состоянии - инструменты действительно в порядке, внедрение .NET Core растет, что является хорошим признаком, появляется все больше и больше интересных проектов, сообщество активно, а такие проекты, как стек SAFE, становятся зрелыми и достигают зрелости. получение достойного усыновления.
Однако, как сообщество, мы до сих пор не решили проблему ремонтопригодности OSS. С одной стороны, в этом нет ничего необычного - большинство сообществ борются с этими проблемами. С другой стороны, очевидно, что коммерческое внедрение F # очень часто происходит благодаря тому, что немногие люди создают отличные OSS-вещи, и, может быть, нам стоит им как-то помочь?
В любом случае, я надеюсь, вы добьетесь больших успехов с F # в 2019 году!