Elixir/Phoenix *

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. Т. е. дальнейшую разработку предполагается провести в рамках парадигмы ООП, расширяя модуль «класса» тактовых генераторов.

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

А потом я написал библиотеку для мутационного тестирования. И понял, что все эти годы мы просто считали, сколько строк кода посещает тестовый раннер, гордясь собой, как малолетние дети, научившиеся считать до десяти.

Пара слов о том, как программисты разных конфессий справляются с самой очевидной задачей в Computer Science.

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

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]

1.      Преамбула

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

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

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

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

С техническими деталями реализации Forth-ibE можно познакомится на сайте GitHub https://github.com/VAK-53/Forth-ibE. Прикладные аспекты Forth-ibE заключены в приложении «ТУ на интерпретатор Forth-ibE» в конце данной статьи.

2.        Патентный поиск. По теме интерпретатор Forth на языке Elixir было найдено достаточно много примеров, но они поставили передо мной задачу, которую я потом решал 3 месяца.

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

Я поломался, поломался — и поломался на осколки. Признаю́: железные помощники Т9 действительно могут приносить пользу в разработке. Единственное, что мне не нравилось — то, что весь проект большой и хорошо натренированной модели не скормишь, а значит — неизбежны потери контекста, размывание смыслов и джойсовские галлюцинации.

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

Когда БЯМ научились подключать сторонние MCP-сервера, произошел качественный скачок. Теперь не нужно файнтьюнить модель, можно файнтьюнить буковку «R» из акронима «RAG». Я-то лучше знаю, как правильно извлекать смыслы из моего личного контента. Если речь про код — лучше всего искать правду в AST.

Так и был зачат Ragex — MCP-сервер для семантического анализа кодовых баз с элементами чёрной магии. Проект, понятно, написан на Elixir, потому что ну а на чем еще?

joerl — это библиотека модели акторов для Rust, вдохновленная Erlang и названная в честь Джо Армстронга, создателя Erlang. Если вам когда-либо приходилось строить конкурентные системы на Erlang/OTP и вы думали: «Эх, был бы здесь хоть намек на систему типов», — то вот она, ваша прелесть. Я начинал этот проект просто потренироваться в расте немного, но меня затянуло и я довел ее более-менее до ума. Сам я на расте писать буду вряд ли, если кто-то ближе к телу захочет попробовать — буду признателен.

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

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

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

Вскрытие показало, что я немного отстал от жизни, и язык программирования «Кровожадный краборжав» уже вполне себе пригоден для написания простеньких хелоуворлдов…

Ладно. В кои-то веки обойдусь без ёрничанья. Официально заявляю: я написал свою первую библиотеку на расте и мне понравилось. Раст — несомненно местами красивый и приятный для работы язык. Написание кода укладывается в зелёный диапазон плотности wtf/sec, а инструментарий заслуживает всяческих похвал (кроме кросс-публикации документации на https://docs.rs/, которая в 2025 году занимает час — хоть донаты шли, её-богу).

Итак, я написал библиотеку, которая позволит эрлангистам проще вкатываться в раст. Акторная модель притворяется краденой из эрланга, с примитивами GenServer и GenStatem, с деревьями супервизоров, с боксированными сообщениями, мэйлбоксами, и привычной терминологией. Библиотека названа joerl, светлой памяти Джо Армстронга, с которым мне посчастливилось быть знакомым, и который сильнейшим образом повлиял на менталитет разработчика во мне.

TL;DR: Cure — это функциональный язык программирования для виртуальной машины BEAM (Erlang/Elixir/Gleam/LFE), который привносит математические доказательства корректности кода прямо во время компиляции. Используя SMT-солверы (Z3/CVC5), Cure проверяет типы зависимые от значений, верифицирует конечные автоматы и гарантирует отсутствие целых классов ошибок ещё до запуска программы.

Проект выходит из стадии «наколенная поделка» и переходит в разряд «MVP».

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

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

Я не верю, конечно, ни в какую демократию (кроме оригинальной афинской 2½ тысячи лет назад, где кворум состоял из трёх с половиной образованных богатых неглупых людей, а остальные были безголосыми рабами и женщинами). Как я уже где-то говорил, существуют исторические свидетельства того, к чему привели первые проявления этой самой демократии: пару тысяч лет назад люди проголосовали распять одного там назаретянина.

Поэтому когда в качестве аргумента за ту, или иную парадигму, — я вижу какие-то индексы, голосования и прочую статистически значимую оценку vox populi, меня это раздражает. «Миллионы мух не могут ошибаться» — так себе аргумент. Поэтому мнение «коммьюнити разработчиков» — практически всегда облыжное, поверхностное, и, в целом, неверное. У каждого в руках свой молоток, а про многообразие саморезов люди en masse если и слышали, то краем уха и в качестве анекдота.

Если экстраполировать мнение большинства и принять его за аксиому, то в мире будут существовать только банковские приложения и круды с базами данных в качестве узкого места и дополнительными серверами вместо корректного горизонтального масштабирования. Тем не менее, многие даже в своей работе используют инструменты, которым никакая база не требуется, а обеспечение роста гарантируется размазыванием нагрузки по кластеру, а не приклеенными (sticky) сессиями. И я говорю не про десктоп.

Несмотря на то, что сам я ушел из большого ООП¹ более десяти лет назад, причем, надеюсь, навсегда, я всегда крайне вяло и неохотно участвую в баталиях тупоконечников и остроконечников: я абсолютно убежден, что для разных типов задач лучше подходят разные инструменты, и выхолощенное ФП заставит всех вокруг создавать тонны никому не нужного бойлерплейта для тривиального круда, а кристальное ООП — воткнет все возможные палки в колёса при реализации бизнес-процессов. Любой из современных языков программирования позволяет смешивать эти подходы, а микросервисная архитектура — даже гостеприимно приютит несколько языков и сред под одной крышей.

Тем не менее, хотя я никогда не считал себя евангелистом функционального подхода, и уж, тем более, не примыкал к стану воинствующих пуристов, меня постоянно свербил вопрос: что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире?

И вот, наконец, меня озарило. Объектная модель всем хороша в однопоточной среде. Даже банальная асинхронность приносит кучу совершенно нерелевантных проблем: мьютексы любого сорта — это порождение дьявола. В игрушечных примерах из книжек они езе как-то работают, но действительно _многопоточный_ код на них написать фактически нереально. Среда, которая буквально приглашает разработчика ошибиться и разрушить тотальность функций потенциальным дедлоком — не должна иметь права на существование в принципе.

Я ненавижу руками создавать бойлерплейты. Любые. Нет, LLM-ки тут тоже не помогут: им надо писать промпты (а потом ещё проверять, что оно там нагенерировало). Мне всегда хотелось, чтобы остов приложения задавался конфигурацией, а я бы только добавлял бизнес-логику. Буквально, в уже сгенерированные для неё места.

Именно в такой парадигме написана моя библиотека finitomata, в которой конфигурация конечных автоматов задаётся текстовым представлением (PlantUML/Mermaid), а бизнес-логика просто распихивается по колбэкам переходов. Но мне этого оказалось мало, и я решил обернуть в такие же абстракции хранение и подписку на изменения.

Так родилась библиотека (пока не опубликована, доступна только в исходниках) persistomata.

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

Так повелось, что математики ограничились применением конечных автоматов к алфавитам, а прикладники тем временем увидели знакомое слово «состояние» и со свойственным всем нам верхоглядством решили, что набор «состояний» и «переходов» — это и есть конечный автомат. Всем, наверное, доводилось видеть такой код: