Elixir/Phoenix *

Раскопал на Medium интересное эссе про Elixir от разработчика Krzyś. Написано так захватывающе и самобытно, что я не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Вот тут первая часть, а это — вторая.

Раскопал на Medium интересное эссе от разработчика Krzyś про Elixir. Написано так захватывающе и самобытно, что не смог пройти мимо. Хотел чуть-чуть подсократить, но каждый раздел важен, а терять стиль автора не хочется. Поэтому разбиваю его на две части — сегодня делюсь первой.

В мире разработки программного обеспечения редко можно увидеть, как зрелый, динамический язык добавляет мощную, статическую систему типов без ущерба для своей философии и существующего кода. 3 июня 2026 года команда Elixir сделала именно это, выпустив версию 1.20. Главное нововведение — постепенная типизация (gradual typing), которая обещает найти в вашем коде «верифицированные баги» (verified bugs — ошибки, гарантированно ведущие к падению в рантайме) без необходимости писать аннотации типов.

Но почему это должно волновать вас, если вы пишете на Python, Java или Go? Команда Elixir поставила перед собой цель, которую многие считают «святым граалем». На практике сочетание всех трёх свойств почти не встречается.

И я считаю, что это отличный повод присмотреться к Elixir, даже если вы никогда не писали на нём ни строчки. Зрелый и интересный язык, работающий на виртуальной машине Erlang (BEAM) и исповедующий функциональную парадигму. Он известен своей отказоустойчивостью и конкурентностью, но, увы, остается малоизвестным языком, и я надеюсь что эта статья заставит вас заинтересоваться Elixir.

«E pur si muove!»
Галилео Галилей.

1. Предисловие

Настоящая статья является важным шагом на пути к созданию демонстратора системы движков, взаимодействующих в потоке данных на базе встроенного интерпретатора Forth в Elixir. Интерпретатор Forth движков описан в предшествующей статье [1]. В серия статей [2, 3, 4] рассказывалось о рабочих моментах разработки демонстратора.

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

Такую же постановку демонстрационной задачи вычисления корней квадратного уравнения на графе обслуживания я сделал 5 лет тому назад в статье «Анти‑Тьюринг», https://habr.com/ru/articles/593379/.

Тогда это был прообраз системы движков. Настоящей реализации демонстратора принципа обработки данных в потоке на Elixir предшествовала работа по написанию встроенного интерпретатора Forth и широкая систематизация движков, шлюзов, кнопок и тактовых генераторов в составе системы.

Перейдём сразу к делу.

1.       Преамбула

Напомню, что в серии статей на Хабре я описываю вольную реализации демонстратора системы взаимодействующих движков Forth в рамках парадигмы обработки данных в потоке. Последняя статья https://habr.com/ru/articles/1002748/ из этой серии была посвящена реализации прототипов взаимодействующих движков Forth класса тактовых генераторов.

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

2.       Исходная точка вопроса

Ход разработки демонстратора системы идет в стиле «два шага вперед, шаг назад». Последний шаг назад, повлекший капитальную модернизацию работающего интерпретатора Forth, был сделан на этой неделе.

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

Справка из Википедии: "REPL — форма организации простой интерактивной среды программирования в рамках средств интерфейса командной строки."

Я не стал копировать из Интернета иллюстрации REPL интерпретатора, а для единообразия подготовил свою, соответствующую интерпретатору Forth:

1.       Преамбула

В литературе по программированию считается хорошим тоном начать демонстрацию средств программирования с примитивной программы, выводящей на экран фразу "Hello, World!".

В разработке системы взаимодействующих движков на Elixir, о которой я писал в статье https://habr.com/ru/articles/1002748/, я как раз подошёл к вопросу отображения поступающих данных телеметрии на экран. Когда были готовы соответствующие базовые модули, я воодушевился идеей повторить знаменитый пример из учебника Кернигана и Ритчи. В результате у меня получилось следующее.

2.       Замысел

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

Термин сток заимствован из событийно-ориентированная архитектуры (EDA). Если угодно, то по-русски это будут выходные отверстий, куда данные "утекают". Напоминаю, что мы разрабатываем систему потоковой обработки данных, где данные находятся постоянно в движении.

3.       Систематизация аппаратных средств

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

Здравствуйте, дорогие читатели! Сегодня я расскажу вам о проекте hornbeam, который переводится на русский язык как "граб" - это такое дерево, похожее на дуб. Он позволяет деплоить сервисы на питоне, используя для этого виртуальную машину эрланга, BEAM (!) А также, позволяет удобно запускать код на питоне, если вы уже используете Erlang или Elixir.

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

Проект задумал и осуществил автор широко известного веб-сервера gunicorn, он адресован широкому сообществу программистов на питоне и эрланге.

4 месяца, 1 700 коммитов, 3 880 тестов, 94.83% покрытие — и ни одной строчки кода написанной руками. Как я построил production-приложение на Elixir/Phoenix силами Claude Code: архитектура процесса, TDD, два production-инцидента и уроки.

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

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

1.      Предыстория

Месяц тому назад я реализовал интерпретатор Forth на Elixir, о чем поведал на Хабре (https://habr.com/ru/articles/985894). Этот гибрид получил составное имя Forth-ibE в честь своих родителей (Forth in-build Elixir).

Следующим шагом разработки стало определение API обмена сообщениями в распределенной команде движков Forth для совместной работы.

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

Во–первых, в [1] говорится, что

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

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

Внешне, формально это похоже на мою задумку команды движков Forth, но понятно, что в [1] описаны движки, размещенные в памяти одного компьютера. В Elixir/Erlang процессы движков Forth получают в распоряжение виртуальные машины BEAM, а следовательно, и узлы.

«Узлы можно запускать как на одном хосте, так и на нескольких. После установления связи между узлами процессы одного узла могут взаимодействовать с процессами других узлов с помощью стандартного механизма обмена сообщениями.»[2]

40 лет тому назад я разработал геометрический язык и написал транслятор чертежей, но бросил разработку на произвол судьбы, так как отчетливо понимал, что по‑хорошему, чтобы транслятор «взлетел», в него нужно встроить интерпретатор простого алгоритмического языка. Честно говоря, я был не готов к этому, и было лень этим заниматься, да и в тот момент я поменял место работы. Все один к одному...

А на днях я закончил разработку интерпретатора Forth (пока без API обёртки), исполнив свой 40-летний долг, после того как мне потребовались числовые движки в узлах ориентированного графа процессов на базе GenServer OTP в Elixir.

Для развития технологии мне требовалось реализовать Forth в объеме, описанном в известном начальном учебнике [1]. Разработанный интерпретатор Forth на языке Elixir получил рабочее название Forth‑ibE, в котором суффикс произносится [айби] и составлен из двух слов: in‑built и Elixir.

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

Когда речь заходит о современных языках системного программирования, разработчики часто сталкиваются с непростым выбором. Два языка, которые привлекают всё больше внимания в последние годы — это Go (разработанный Google) и Crystal (вдохновлённый синтаксисом Ruby, но со статической типизацией). Оба обещают высокую производительность, продуктивность разработки и современные возможности языка, но идут к этим целям совершенно разными путями.

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

Заголовок настоящей статьи расшифровывается просто — в ней рассказывается о реализации транслятора описания графа на языке dot при помощи генераторов лексера и парсера leex и yeek в структуру графа пакета libgraph. Реализация выполнена на платформе языка Elixir, который занимает подобающее место на заставке.

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

Elixir - язык, вызвавшийся заново открыть Erlang современному миру. Синтаксис без приятных сердцу, но уже архаичных знаков пунктуации; культура разработки с особым вниманием к качеству и удобству инструментов; полноценный набор решений для написания web-сервисов; стандартная библиотека без груза в несколько десятилетий и настоящие макросы.

Если задуматься, то непосредственно в самом языке не так уж и много нового. Действительно, зная и Elixir и Erlang, можно представить как код на одном языке будет выглядеть на другом. Хотя и не всегда - в Elixir имеются выражения, которым нет эквивалента в Erlang. Как же они работают? Очевидно, Elixir раскрывает их в какой-то дополнительный Erlang код на этапе компиляции. Иногда можно интуитивно представить в какой, а иногда (спойлер) компилятор может подкинуть пару сюрпризов.

Эта статья - обзор преобразований, которые проходит код на Elixir прежде чем попасть в компилятор Erlang. Мы посмотрим на условные выражения вроде if и cond, уделим внимание точке, посмотрим на приключения с with и for, приоткроем тайны протоколов и удивимся оптимизациям, которые Elixir умудряется производить.

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

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

Хотя Elixir и молодой язык, но видно, что разработчики языка уделяют большое внимание просветительской работе и изданию разноплановых учебников. С удовольствием читаю и перевожу книги по применения Elixir издательства The Pragmatic Bookshelf. Дошла очередь и до книги «Metaprogramming Elixir» Крис Маккорда (Chris McCord), которая занимает особое место в библиотеке по Elixir.

Цитата из аннотации этой книги:

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

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

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

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

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

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

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

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

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

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

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

Elixir — удивительный язык, и для меня было огромной привилегией работать с ним уже более десяти лет (как летит время)!

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

Вы вносите несколько изменений в один файл в своей кодовой базе и нажимаете «перекомпилировать». Бум: Compiling 93 files (.ex). Затем вы вносите еще одно изменение и бум: Compiling 103 files (.ex).

Мы все через это проходили. У этой проблемы есть решение. Будет ли решение болезненным, зависит от того, как долго эта проблема оставалась нерешенной в вашей кодовой базе.

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

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

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

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

Укрепите цикл обратной связи: если вы меняете один модуль, в идеале перекомпилировать следует только один модуль. Если вы занимаетесь локальной веб-разработкой, ваша локальная страница должна загружаться практически мгновенно. Из этого правила есть исключения, но если вы исключение, вы осознаете, что вы исключение.

Шаг 1: Обнаружение проблемы

Ну, обнаружить легко: вы меняете один модуль, и несколько перекомпилируются? Да, вы в аду перекомпиляции. Но как узнать, в каком круге ада вы находитесь?

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

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

В этой статье мы рассмотри основные инструменты для реализации распределённых вычислений Elxir.

Я фулстек-разработчик, индивидуальный предприниматель. По моему опыту, один из самых востребованных классов проектов, за разработкой которых к нам обращаются, — приложение для работы в режиме реального времени. Конечно, вам такие приложения известны: WhatsApp, Discord, Slack, т.д. При разработке приложений для работы в режиме реального времени следует учитывать различные факторы, в частности, масштабируемость, отказоустойчивость, отзывчивость и распределённость. Это задача не из лёгких, в особенности для небольшой команды или разработчика‑одиночки.

Но что если бы я вам сказал… что можно создавать приложения для работы в режиме реального времени, которые можно масштабировать более чем на миллион пользователей силами всего нескольких разработчиков? К тому же, такие приложения можно было бы развёртывать почти без задержек и ценой минимальных затрат. Здесь я имею в виду, что для этого нужно освоить секретное оружие под названием «Виртуальная машина Erlang» или BEAM (Абстрактная машина Богдана/Бьёрна для языка Erlang).