Elixir/Phoenix *

Если на Силикатной улице (это в Мытищах) остановить тысячу случайных прохожих и спросить их, на каких трёх слонах покоится ООП, каждый второй назовёт инкапсуляцию. В коридорах МИФИ, или на собеседовании в Яндексе — процент будет даже выше. Даже LLM способна на шести пальцах объяснить, почему.

И, тем не менее, ООП — один из худших способов обеспечить инкапсуляцию. Идолопоклонники на этом месте могут поставить тексту, мне и вселенной — минус, остальным я на примерах попытаюсь объяснить, что побудило меня к столь резкому заявлению.

Книги делятся на две категории: fiction и non-fiction. Технические книги — внезапно — не исключение, и поддаются точно такой же классификации. Между учебником по научной дисциплине, начинающегося с аксиоматики и продолжающегося доказательствами теорем, — и практически любой современной литературой по «Computer Science» — лежит пропасть. Что происходит, когда люди долгое время оказываются рабами одной-единственной книги (с продолжениями), нам хорошо известно из истории. Возникает религия.

99% процентов литературы по ООП — это талмуд. Вероятность того, что вам подойдет «паттерн» — примерно 50%. Как встретить динозавра на Невском. Знание паттернов полезно в той же степени, что и теология, — и примерно тем же по специальности людям. Всегда полезно уметь отличать по запаху Пана от простого фавна, но практических применений такой эрудиции — не существует.

Когда Грубер со Шварцем выкатили маркдаун, он был как глоток свежего воздуха. Минимум разметки, читаемый текст даже до обработки, достаточный для рядового средней руки блогера набор красивостей.

Спустя пару лет мне стало мучительно недоставать возможности тонкой настройки. Я никогда не использовал маркдаун для разметки научных статей и документов с вложенными в нумерованные списки таблицами, а CommonMark двигался, почему-то, именно в этом направлении. Не, серьёзно, цитата с вложенной таблицей, в одной из ячеек которой — список? Кому вообще может прийти в голову реализовывать это на маркдауне?

Один из самых вредоносных принципов в разработке, когда-либо получивших широкую известность — YAGNI. Его озвучил Рон Джеффрис в 1998, а спустя более двадцати лет — еще и Кармак подлил керосин в огонь со своим: «Неопытным разработчикам трудно оценить, как редко разработка архитектуры с учетом будущих требований приводит к успеху».

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

— Давай предусмотрим передачу конфигурационных параметров в эту функцию? — YAGNI.
— Инъекция зависимости здесь уместнее приколоченной гвоздями реализации хранилища. — YAGNI.
— Черный кофе без сахара, пожалуйста. — YAGNI!

Зайду с козырей: КДПВ этой заметки имеет прямое отношение к тексту.

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

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

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

Но если речь идёт о понимании парадигмы, людей обычно спрашивают примерно о таких вещах:
  ▸ [junior] чем отличается GenServer.call/2 от GenServer.cast/2 и от Process.send/3
  ▸ [middle] как реализована модель синхронных вызовов (GenServer.call/2) и зачем в колбэке нужен второй параметр
  ▸ [middle] зачем нужен колбэк init/1 и в каких случаях из него имеет смысл вернуть кортеж {:ok, state, {:continue, arg}}
  ▸ [senior] как перенести процесс на другую ноду

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

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

Иногда проблему можно решить пулл реквестом, иногда — хаком (спасибо Матцу за доверие к разработчикам, в руби скрыть вообще ничего нельзя, но и в менее дружественных к подкостыливанию языках — есть всякие рефлекшены, аспекты, указатели на сырую память, наконец). Наконец, можно форкнуть библиотеку, экспортировать всё, что нужно — и окунуться в ад поддержки форка. Особенно это досадно в иммутабельных языках: ну зачем что-то там от меня скрывать, если я все равно ничего испортить в вашем коде не смогу?

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

Другая команда подошла к вопросу посерьезнее, и разгорелся жаркий спор, как мы будем передавать прожаренные данные в монолит. HTTP грозило отыквиться из-за больших объемов и плотностей, RabbitMQ надо было привинчивать на уровне инфраструктуры (а это, как вы понимаете, занимает три года), какой-то хипстер из молодых предложил кафку, а бородатый чувак в свитере пробубнил про event triggers прямо в постгресе.

Спустя минуты три жаркой дискуссии, я сказал: «C’mon guys. It’s irrelevant now. Just let me know when you have it settled». Лид команды монолита сдержанно хихикнул и спросил: «В смысле „всё равно“?». Я пожал плечами и ответил: «Я прикручу выбранный вами способ за два часа, всё в порядке, пошли работать».

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

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

Когда заходит разговор про эрланг/эликсир, людям обычно приходит на ум три основные ассоциации: легковесные процессы, акторная модель, отказоустойчивость. Эрланг позволял запускать сотни тысяч (при тонкой настройке виртуальной машины — миллионы) «процессов» (того, что потом назвали гринтредами, а еще позже — горутинами) — почти сорок лет назад. Джо Армстронг в своей диссертации полушутя охарактеризовал язык через катахрезой everything is a process. С акторной моделью — понятно, это прямое влияние Алана Кая и его идей насчет everything is an object (sending messages to each other).

В тексте ниже я покажу, как сохранять состояние между падениями и перезапусками процесса — без сторонних хранилищ и СМС.

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

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

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

Уже более двадцати лет в индустрии принято тестировать написанный код до выкатывания его в продакшн. Люди придумали unit-тесты, acceptance-тесты, интеграционные тесты, property-based тесты. Люди даже придумали TDD, чтобы удостовериться в том, что тесты на самом деле работают. Люди придумали моки и контракты, наконец (настоятельно рекомендую прочитать эту заметку Валима, она буквально открыла мне глаза на то, что не так с моками в большинстве случаев).

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

TL;DR: решение задачки Эйнштейна на прологе и объяснение, зачем мне вообще пролог в 2025 году.

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

Наконец, мне все это надоело. Заколачивать утюгом шурупы — весело, но малоэффективно. Я даже попробовал прикрутить Coq, но микроскоп тоже плохо подходит для довольно грубой работы с шурупами. И тут меня осенило: пролог же. Оффтопик: почему-то вика в этом месте не переведена на русский язык, если эту заметку читает кто-то, кому не противно редактирование вики — сделайте доброе дело, пожалуйста.

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

В декабре 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).