В декабре 2024 г. вышел релиз v1.18 языка Elixir. Настоящая статья — обзор этого события в мире программирования с точки зрения анализа тенденций усовершенствования уровня экосистемы Elixir и прогноза развития языка.

Наверное, я самый безрассудный российский программист, что взялся за такой обзор, по двум причинам:

1. Есть более значимые эксперты по Elixir, чем я, но они очень заняты.

2. В конце статьи я раскрою, чего жду от языка Elixir.

Обзор релиза Elixir v1.18 базируется на информации из официальной публикации Хосе Валима от 19 декабря 2024г. «Elixir v1.18 released: type checking of calls, LSP listeners, built-in JSON, and more».

Обзор является концептуальным разбором «полётов» и не содержит примеров кода Elixir, т.к. отечественный читатель вряд ли ждет деталей на уровне кода. Почему я так считаю: сайт Curiosum (https://curiosum.com/surveys/elixir-2024) в 2024г. проводил ежегодный опрос 500 программистов на Elixir. От огромной России в опросе участвовало всего 7 респондентов, тогда как из небольшой Польши почти в 6 раз больше — 40.

Отдельные положения обзора отражают точку зрения автора, которые он постарался сверить с мнениями зарубежных программистов на Elixir, участвующих в форумах https://elixirforum.com/ и https://www.reddit.com/. Основным я посчитал второй, т.к. он более живой и эмоциональный, а это всегда импонирует. А первый форум более деловой и «пуританский». Статус обязывает, т.к. его курирует сам Хосе Валим.

Итак, начнем. Перечислим основные улучшения Elixir v1.18:

• теоретико–множественные типы;

• языковые серверы;

• встроенная поддержка JSON;

• новые возможности библиотеки модульного тестирования.

Система типов Elixir.

Еще в Elixir v1.17 в компилятор были включены типы: целое число, число с плавающей точкой, двоичное число, pid, ссылки, порты, атомы и словари.

В Elixir v1.18 система типов расширена типами:

• sound — типы, выведенные и назначенные системой типов, соответствуют поведению программы;

• gradual — система типов Elixir включает тип dynamic(), который может быть использован, когда тип переменной или выражения проверяется во время выполнения. При отсутствии dynamic() система типов Elixir ведет себя как статическая;

• developer friendly — типы, описанные, реализуемые и составленные с помощью основных операций над множествами: объединения, пересечения и отрицания.

(Поэтому система теоретико–множественных типов).

Не вдаваясь в подробности, приведём заявление разработчиков языка:

«Релиз продвигает нас дальше в обеспечении проверки типов и вывода типов существующих программ на Elixir, не требуя от разработчиков Elixir явного добавления аннотаций типов».

и обратимся к комментариям пользователей на форуме Reddit о типах:

« … я ненавижу "unless". Сегодня я работаю над Ruby–проектом, в котором линтер навязывает его в миллионе мест, а я все еще путаюсь. Даже после года работы с ним.
Мне даже все равно, насколько суперинтересны темы о типах (действительно захватывающие), или iex с горячей перезагрузкой, или даже API JSON native».

Комментарий на комментарий:

почему-то разговор на форуме по теме нового релиза Elixir начался с обсуждения отмены unless? И вопрос макроса unless растянулся на полфорума. Западные программисты так эмоционально отреагировали на такую вещь, как макрос unless. Как вы знаете, в Elixir почти всё является макросом.

Ещё один комментарий:

 «… я очень рад появлению системы типов, LSP и JSON в stdlib»;

И это всё. Всего два упоминания о типах после такой рекламной подготовки. А ведь командой разработчиков проведена действительно впечатляющая работа. Переходим к следующей теме:

Слушиватель языкового сервера (LSP)

Анонс LSP:

«До настоящего момента все реализации языкового сервера имели собственную среду компиляции….

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

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

«Удивительно, очень рад изменению компиляции LS, рад, что оно включает iex. Мне постоянно приходится уничтожать папки deps, build и elixir LS, чтобы снова все синхронизировать. Кроме того, я часто использую iex -S mix, и я постоянно перекомпилирую или забываю это сделать» .

Однако на Reddit есть еще одна свежая тема «Когда выйдет официальный LSP?». Посмотрим, что актуального там:

«Привет! Я член команды LSP.
К сожалению, у нас пока нет точных сроков.
Но чтобы прояснить ситуацию, которую я видел, релиз не выйдет с Elixir 1.18».

В общем ситуация неясная. Дождемся — попробуем.

Встроенный JSON

Оказывается, Erlang/OTP 27 добавил ранее встроенную поддержку JSON , и разработчики перенесли поддержку модуля в Elixir. Новый модуль называется JSON. Его основные API отражают API старого доброго Jason, де-факто библиотека JSON в сообществе Elixir до этого момента.

Трудно сказать, что от этого выиграют разработчики на Elixir. Радует, что API производного протокола для структуры является зеркальным отражением старого API из Jason.

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

Параметризованные тесты и группы ExUnit

ExUnit теперь поддерживает параметризованные тесты. Это позволяет тестовым модулям запускаться несколько раз при разных параметрах.

«До параметризованных тестов Elixir прибегал к генерации кода, что увеличивало время компиляции. Кроме того, ExUnit параметризует целые тестовые модули, что также позволяет различным параметрам работать одновременно, если async: true задана такая возможность. В целом, эта функция позволяет вам компилировать и запускать несколько сценариев более эффективно».

Имхо, получается, новый релиз Elixir — это академическая последовательная кропотливая работа по улучшению экосистемы языка. Качественных изменений пока не видно, но сообщество всё ещё надеется на революционные прорывы в технологии в духе Джо Армстронга. В языке Elixir для этого заложен фундаментальные основы.

Опрос Curiosum

Как уже говорилось, сайт Curiosum в 2024г. проводил ежегодный опрос 500 программистов на Elixir. Опрос состоял из 25 вопросов.

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

Нас могут заинтересовать результаты обработки ответов на некоторые вопросы. Например, на вопрос

6. Как вы оцениваете свою удовлетворенность следующими аспектами Elixir?

Обобщение:

Это вопрос, ответ на который больше всего интересен организаторам опроса. Неудивительно, что параллелизм и радость разработки вышли на первое место — это, несомненно, суперспособности Elixir.

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

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

А вот самый интересный 9 вопрос:

9. Какие из следующих архитектур, шаблонов или подходов вы используете или предпочитаете в своих проектах Elixir?

Обобщение:

Монолитные архитектуры являются явными фаворитами — более трех четвертей респондентов указали, что они «предпочитают» монолиты. Проектирование на основе доменов (DDD) и событийно-ориентированной архитектуры также демонстрируют солидный интерес, хотя большинство респондентов используют их лишь изредка.

Последний вывод относительно событийно-ориентированного подхода должен привлечь наше наибольшее внимание, т.к. он совпадает с высказанным на Хабре прогнозом о перспективном направлении развития Elixir. (см. публикацию Назначение языка программирования Elixir).

Предпосылки развития Elixir в направлении парадигмы обработки данных в потоке

Сначала необходимо пояснить терминологию. Как я разграничиваю событийно‑ориентированную архитектуру (EDA) и обработку данных в потоке или data streaming architecture (DSA).

Обе парадигмы, EDA и DSA, работают с данными, поступающих от датчиков, только EDA обрабатывает их централизованно, а DSA — децентрализованно. Поэтому на нижнем уровне со стороны сенсорных хабов они как близнецы.

В качестве примера приведу реализацию метеостанции на микрокомпьютере Raspberry Pi помощью Elixir и Nerves из книги «Build a Weather Station with Elixir and Nerves» трёх авторов A.Koutmos, Bruce A. Tate, F.Hunleth.

Авторы описывают общую архитектуру сбора данных с метеостанций с консолидацией метеоданных при помощи Phoenix через протокол http в единой базе данных PostgreSQL. Это типичная EDA.

Но возможен и другой, перевернутый вариант архитектуры — фреймфорк Phoenix инсталлирован внизу на сенсорном хабе и пересылает клиентам метеоданные по подписке через каналы WebSocket. Подписчиков на рассылки может быть много. Надеюсь, что такая архитектура DSA в духе IoT нравится не только мне.

На нижнем уровне независимо от архитектуры промежуточного уровня (в DSA непонятно, где верхний уровень: каждый уровень может быть надстроен следующим) датчики в Elixir принято оборачивать в GenServer OTP, код которого ждет установленный интервал времени между считываниями измерений. Очень удачна идиома для программы чтения с датчика. Если нужен регулятор на основе PID‑алгоритма, то можно просто добавить еще два GenServer‑а: сумматор и привод управления.

Проблема в том, что Nerves фактически живет только на микрокомпьютере, например, Raspberry Pi, а это накладно. Нужна миграция Elixir на микроконтроллеры. Как‑то мне попадалась информация на elixirforum.com/, что Elixir не живет на популярных микроконтроллерах STM32 с политикой стабильной цены не более 3$, т.к. на них нельзя реализовать BEAM.

Я не поленился, зашёл на официальный сайт Erlang и обнаружил в разделе «Is Erlang small enough for embedded systems?» интересующую нас информацию:

«Люди успешно запускают реализацию Erlang от Ericsson в системах с объемом оперативной памяти всего 16 Мбайт. Достаточно просто разместить сам Erlang в постоянном хранилище объемом 2 Мбайт (например, на флэш‑диске)».

Этот требование является пока неподъёмным для микроконтроллеров. Но в памяти засело воспоминание о статье на Хабре «Erlang для IoT» за 2018г. В ней были перечислены доводы в пользу переноса Erlang на микроконтроллеры. Может это и явилось отправной точкой моих мыслей в этом направлении.

Самое замечательное, что в статье рассказывалось об успешном опыте реализации Erlang на конструкторе LinkIt Smart 7688 от компаний Mediatek и SeeedStudio. Стоимость этого конструктора 22$. Было приятно осознавать, что процесс пошёл!

Настоящий обзор был уже готов, когда я открыл для себя сайт AtomVM. На сайте говорится:

AtomVM — это облегчённая реализация абстрактной виртуальной машины BEAM, которая может выполнять инструкции байт-кода, скомпилированные из исходного кода Erlang или Elixir. AtomVM поддерживает ограниченное, но функциональное подмножество опкодов BEAM, а также включает небольшое подмножество стандартных библиотек Erlang/OTP, все из которых оптимизированы для работы на крошечных микроконтроллерах.

И все это на устройстве, которое может стоить всего 2 доллара!

Поддерживаемые платформы:

• Linux, macOS, FreeBSD, DragonFly ( generic_unix )

• ESP32 SoC (с IDF/FreeRTOS, см. esp32 )

• Микроконтроллеры STM32 (с LibOpenCM3, см. stm32 )

• и т.д.

Надо пробовать на ESP32.

Больше я не буду задерживаться на теме AtomVM и микропрограммирования контроллеров на платформе Erlang/Elixir.

Вернемся к промежуточному уровню DSA. Для того, чтобы более ясно осознать, что она из себя представляет и что нужно для неё сделать, преобразуем знакомую и знаменитую формулу Н. Вирта. Предлагается следующий её обращённый вариант:

«Структура алгоритмов + данные = программы»

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

«Если бы все приложения в мире общались по сокетам и лисповским S‑выражениям и имели бы стандартные описания протоколов обмена, — тогда мы бы могли намного эффективнее повторно использовать код. Сегодня концентрация языков и различных методов огромна, но то, как объединять эти методы воедино реализовано крайне плохо. Изучайте протоколы, а не языки».

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

Но при таком развитии ситуации многое в Elixir может поменяться. Например, должна поменяться стратегия «Let it crash», т.к. она работает только в среде слабосвязанных узлов алгоритмов.

Скажите, что это ни чем не подкреплённая гипотеза. А вот и нет. Такой подход в ИИ называется Large language model (LLM). Я не специалист в области нейросетей, поэтому могу и ошибиться с аналогией, но я точно знаю, что

1.     такая модель имеет право быть в системах управления,

2.     идиомы Elixir/Erlang полезны для создания приложений IoT.

Вот такие мысли посетили меня по поводу нового релиза Elixir.