Назначение языка программирования Elixir

Я являюсь в России одиноким поклонником языка программирования Elixir. Почему я делаю такой пессимистичный вывод.

В России язык Elixir не пользуется популярностью:

• русскоязычные сайты, посвященные Elixir, постепенно умирают или уже умерли;

• вакансий программистов Elixir я не встречал, (видел только на Украине);

• статьи по Elixir в русскоязычном сегменте Internet в основном переводные;

• переведенных на русских язык книг по Elixir всего две:

1.     для начинающих “Введение в Elixir” С. Сенлорен и Д. Эйзенберг

2.     достойная книга “Elixir в действии» Саши Русич.

Обе книги были переведены издательством ДМК.

Язык Elixir является молодым языком, но считается быстроразвивающимся. На Западе, судя по форумам, у него появилось много сторонников. Но оказалось, что и там вакансий для программистов Elixir очень мало: видел объявление о вакансии, на которую претендовало несколько сотен кандидатов.

Всё это заставляло меня часто задумываться о перспективах Elixir. И возможно, я понял в чем дело. Далее я выражаю своё субъективное мнение о назначении этого языка.

Уже после написания этой заметки я обнаружил на англоязычном форуме https://www.reddit.com/r/elixir/ обсуждение аналогичной темы: «Beyond the joy of coding, what makes you bet on Elixir for the future?» («Что заставляет вас делать ставку на Elixir в будущем помимо удовольствия от программирования?»), отдельные высказывания и характеристику в целом я приведу в конце.

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

Но одну подмеченную особенность Elixir хочется всё же назвать. Помимо вычисления на стеке у Elixir имеется дополнительный «движок» на базе посылки сообщений для управления процессами реального времени. Таким образом произошло разделение механизмов исполнения математических вычислений и посылки сообщения между процессами. Механизм сообщений унаследован от языка Erlang.

Приведу цитата из книги David Thomas «Programming Elixir», которая, надеюсь, даст читателю некоторый зрительный образ распределенных акторов Elixir:
«Erlang и, как следствие, Elixir-программы часто структурированы как наборы взаимодействующих субприложений. Часто код, который в другом языке был бы библиотекой, в Elixir является субприложением. Это поможет представить их как компоненты или сервисы.»
Здесь компоненты, сервисы — теоретически синонимы акторов.

Ну, с Erlang всё понятно: он уверенно занял специфичную нишу ПО для коммутационного оборудования. Для Elixir это ниша уже занята. Но есть область, которой акторы Elixir соответствуют оптимально. Это программирование в парадигме обработки данных в потоке, или cобытийно-ориентированной архитектуры.

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

Если вы не верите мне, то сошлюсь на фундаметальный учебник по программированию Х. Абельсона и Д.Д. Сассмана «Структура и интерпретация компьютерных программ», в котором есть описание и подробный рассмотрение разделения программирования на два стиля: программирование объектов в общей памятью и потоковое программирование.

Таким образом, мы имеем два полюса в программировании:

• приложения с централизованной обработкой данных,

• приложения потоковой обработки данных.

Технологию последних приложений , например, демонстрирует Apache Software Foundation с помощью компонентов Kafka.

Вернемся к языку Elixir. Несмотря на универсальность языка Elixir, позиционировать применение Elixir в приложениях с централизованной обработкой данных я бы не рекомендовал: эта область уже занята и хорошо обжита традиционными языками, такими как Java, Python, C, C++ и т.д.

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

На верхнем уровне я мог бы сослаться на наличие готовых шаблонов серверов OTP GenStage, Flow, Brodway, но я лучше приведу в пример свой личный опыт реализации многопортового коммуникационного контроллера обработки данных в потоке на Elixir.

В моём потоковом коммутационном контроллере данные в цикле снимались с датчиков шины Modbus. (В дальнейшем планировалось дополнить интерфейс нижнего уровня шиной CAN или i2c по требованию заказчика.) Тут же данные без задержки транспортировались на верхний уровень через канал WebSocket по подписке.

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

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

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

Теперь обещанный выборочный «разбор полёта» на англоязычном сайте в гугловском переводе.

kyleboe:

“Говоря о технической стороне вопроса: основы Elixir соответствуют современной архитектуре ЦП. Erlang/BEAM изначально запускает процессы, которые можно распределить по ядрам ЦП, чтобы использовать весь потенциал оборудования.

Для меня такое соответствие добавляет радости от написания Elixir. Мне не нужно думать/беспокоиться об использовании ресурсов. В качестве конкретного производственного примера я недавно перенес API с Ruby на Elixir и сократил стоимость нашей инфраструктуры на 95%.”

legendary_sandwich:

“Если бы мне пришлось выбрать что-то одно, что заставляет меня делать ставку на Elixir, я бы сказал, что это его основная команда. Я использую Elixir с версий 0.*, и, по моему мнению, эти ребята были довольно последовательны в движении в правильном направлении. Что-то в том, что я все еще вижу огонь в глазах Хосе после всех этих лет, заставляет меня думать, что это безопасная ставка.”

dipittydoop:

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

the_jester:

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

directionamagnitude:

“Мы используем Elixir в производстве уже 6 лет и не отстаем от ведущих версий Elixir и Phoenix. Я никогда не работал с платформой, у которой было бы так мало проблем во время обновлений. Это откровенно феноменально и позволяет мне не беспокоиться о консолидации нашего стека вокруг Elixir. Я уверен, что решения Хосе и Криса МакКорда поведут платформу в позитивном направлении и не оставят нас с основными версиями языка/платформы, которые мгновенно сделают наши огромные инвестиции устаревшими.”

a_rather_small_moose:

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

Пакеты в экосистеме хорошо спроектированы и хорошо информированы. Ecto — особенно яркий пример.

Сам язык не очень полиморфен, а сопоставление с образцом позволяет применять агрессивное программирование, что позволяет выявлять проблемы в коде на более ранних стадиях.

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

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

После комментария о мягком реальном времени, что совпадает с нашим выводом, наверное, достаточно положительных отзывов. Но есть один отрицательный комментарий:

TyrusX:

“Моя компания сделала ставку на будущее Elixir 4 года назад. Сейчас мы глубоко в фазе «что мы сделали». Наши затраты намного выше, чем у аналогичной компании, в которой мы работали, и где все было сделано на Python и TypeScript, от разработчиков до инфраструктуры.”

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

Выводы

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