Erlang/OTP *

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

Именно так устроен мир программирования. Проблема очевидна любому, кто хоть раз пытался написать инструмент для анализа кода. Допустим, вы создали превосходный анализатор цикломатической сложности для Python. Он великолепен: находит вложенные условия, считает точки ветвления, рисует графы потоков управления. Затем к вам приходит коллега и спрашивает: «А для Ruby сделаешь?» И тут выясняется, что весь ваш труд – все эти обходчики деревьев, все эти паттерн-матчинги над питоновским AST – нужно переписать заново. С нуля. Для другого дерева, с другими узлами, другой семантикой и другими подводными камнями. А потом придет третий коллега и попросит то же самое для Haskell.

Пока мы ждём, что в Telegram наконец раскатится обновлённая реализация Fake-TLS, хочу рассказать о своей реализации MTProto-прокси 2018 года, которая снова становится актуальной, и об одной из её уникальных возможностей.

MTProto-прокси — решение для обхода блокировок Telegram в странах с интернет-цензурой (мы говорим про Иран конечно же 😄). Типичная схема выглядит так: оператор поднимает прокси с одним секретным ключем на всех, публикует одну ссылку, и тысячи людей ей пользуются. Просто, но у этой модели есть реальные ограничения:

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

Нет аналитики на пользователя. Видно общее число соединений и IP-адреса, но не понять, кто активен, кто раздал свою ссылку полусотне друзей и кто потребляет весь ваш трафик.

Ограниченная монетизация. Да, есть “спонсорские каналы”, но если хотите продавать доступ — не за что зацепиться: секрет один на всех, привязать подписку не к чему.

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

У меня двадцать лет в IT. Большую часть этого времени я проектировал и эксплуатировал инфраструктуру на PostgreSQL. Сейчас работаю архитектором: Go, Python, Postgres, Redis, ClickHouse, мониторинг на десятки тысяч баз. До этого писал на Ruby, пробовал Rust. Классический бэкенд-инженер со всеми вытекающими привычками: императивный код, мутабельное состояние, постоянные if err != nil { return err }.

А потом я начал писать бэкенд на Gleam — молодом функциональном языке на BEAM (Erlang VM), который появился в стабильной версии только в 2024 году. Навык ещё в разработке, но бэкенд уже работает, и я не жалею. Путь был... познавательным.

Эта статья — не туториал и не рекламный буклет. Это честный рассказ о том, почему я выбрал Gleam, какие шишки набил, что мне понравилось настолько, что я не хочу возвращаться, и что до сих пор бесит.

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

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

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

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

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

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

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

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

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

Задумывались ли вы когда-нибудь, как построить самое стабильное приложение в мире? Какими свойствами оно должно обладать и какие архитектурные подходы делают это возможным? Впечатляет, что приложения вроде Discord и WhatsApp выдерживают миллионы одновременных пользователей, тогда как другие задыхаются уже на нескольких тысячах. Сегодня посмотрим, как Erlang позволяет обрабатывать огромную нагрузку и при этом держать систему живой и стабильной.

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

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

Три способа менять один объект из нескольких потоков. Больше нет

Mutex, CAS, акторы, STM, CRDT, иммутабельность, MVCC, Disruptor…

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

На самом деле их ровно три. Всё остальное — реализации и комбинации.

Эта статья — попытка навести порядок в голове. После неё вы сможете:

за 5 секунд классифицировать любой подход к конкурентности;
понимать, почему Erlang выбрал акторы, а Java предлагает synchronized;
не изобретать велосипеды и не зацикливаться на «единственно правильном» решении;
проектировать многопоточный код, держа в голове простую модель.

Заодно, покажу почему ООП вообще не было изначально спроектировано под многопоток.

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

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

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

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

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

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

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

Код некоторых модулей Erlang/OTP старше, чем большинство современных junior-разработчиков. Эти файлы — настоящие цифровые патриархи, десятилетиями обеспечивающие работу банковских транзакций, телефонных сетей и систем обмена сообщениями. Мы решили заглянуть под "капот" этого языка-долгожителя, чтобы проверить, что именно скрывается в строках, на которые сегодня полагаются миллионы пользователей. А вот что мы нашли, узнаем в этой статье.

Как построить микросервисы на RabbitMQ так, чтобы система не падала каскадом, а деградировала предсказуемо: outbox, mandatory, AE, идемпотентность, DLQ, приоритеты и реальные грабли из продакшена

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

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

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

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

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

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

Рассказ рассчитан на тех, кто хотя бы поверхностно знаком с концепциями ООП и (или) ФП. Ниже вы не найдёте всех тех запутывающих псевдонаучных объяснений, которые вам услужливо предоставит Вика или Анжела (или как там вы называете свою любимую LLM в приватных чатиках).

Текст написан именно сегодня, когда Алану Каю исполнилось 85! Поздравляем, Алан, ты — гений, спасибо тебе за всё!

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

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

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

В любой мало-мальской экосистеме обязательно будет такая штука, как «job runner». Чтобы линейный, простой как полено, код — мог иметь дело с длительными вычислениями. Нужен отчёт, а его генерация занимает полчаса? — Нет, мы не сделаем правильно, не поправим наши схемы, не озаботимся триггерами и persistent views, на это у нас нет ни времени, ни денег, мы стартап, поэтому делегируем: пусть весь неэффективный медленный код идёт в жобу!

Когда к нам пришел докер и — как тот муж из анекдота — перее^W научил нас отказоустойчивости на свой манер, я написал бесчисленное количество костылей, чтобы действительно отказоустойчивый (а главное, долгоживущий) код продолжал нормально работать в условиях, где сброс горячего кэша из-за внезапного перезапуска контейнера, вызванного близостью Андромеды к Меркурию, — норма.

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

С этим надо было что-то делать, и я написал библиотеку на обоих используемых тогда в компании языках (руби и эликсире), позволяющую поддерживать общую конфигурацию приложения из нескольких источников, обновлять её в режиме реального времени через изменение этих самых источников (поменял значение в консуле/редисе/локальном джейсоне — и оно автоматически обновилось в конфиге, а уведомления разослались всем заинтересованным).

Больше двадцати лет назад мне довелось поработать в одном берлинском стартапе, где мы пилили визуальную трансформацию UML в код и обратно. Пользовательский интерфейс на свинге, изоморфная (в теории) обработка кода и диаграмм — на хаскеле. Было весело, потом полопались доткомы, кончилось финансирование и мы еще почти год пытались как-то дотянуть до продукта без денег. Капитализм победил, и продукт погиб (насколько я знаю) — так и не родившись.

Из интересного (помимо того, что я сам нарисовал почти полсотни иконок для нашего приложения, что до сих пор считаю самым выдающимся собственным достижением в IT) — там был придуманный и воплощенный мной механизм Undo/Redo, о котором я и собираюсь сегодня рассказать.

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

Как ту же самую задачу решает несдержанный на язык швед финского происхождения?…