Автор исследует, сколько усилий требуется для реализации собственных примитивов BEAM, создавая упрощенную версию виртуальной машины на Elm. Используя стиль передачи продолжений (CPS), он избегает необходимости писать парсер, CLI и другие компоненты полноценного компилятора, сосредоточившись на ядре системы. Этот подход позволяет сосредоточиться на основных концепциях, таких как планировщик, процессы и их взаимодействие.

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

• Обсуждение в основном вращается вокруг BEAM: его происхождение, ограничения и будущее.
• Участники обсуждают, что BEAM не переносим между дистрибутивами Linux, в отличие от JVM, и требует компиляции из исходников.
• Поднимается вопрос о том, что написание статьи не объясняет читателям, что такое BEAM, и что это значит для них.
• Некоторые участники предлагают использовать Nix или статически слинкованный BEAM для решения проблемы портируемости.
• Также обсуждается, что исходный код BEAM доступен, и что ранние версии BEAM, возможно, были бы полезны для изучения.

Проект OTP от команды gleam-lang предоставляет инструменты для создания отказоустойчивых многопоточных программ с использованием модели акторов. Реализация переносит мощные концепции Erlang OTP в экосистему языка Gleam, предлагая разработчикам современный подход к построению распределенных систем.

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

• Обсуждение началось с восторженного отзыва о Gleam и его преимуществах, но быстро перешло в сравнение с Erlang/OTP и обсуждение того, что такое actor-модель и как она справляется с распределённым состоянием.
• Участники обменялись мнениями о том, какие языки/подходы лучше подходят для BEAM-стека, и подняли вопрос о том, что именно делает Erlang уникальным и какие у него есть ограничения.
• Также было затронуто, что такое влияние имеет выбор языка на разработку DSL и встраивание в другие системы, и почему транспиляция в Lua не рассматривается как цель.
• В конце обсуждение сошлось на то, что выбор инструмента в конечном счёте сводится к личным предпочтениям и конкретному проекту.

Команда GRiSP достигла ключевого рубежа в портировании JIT-компилятора Erlang BEAM на ARM32: впервые выполнила функцию Erlang через сгенерированный машинный код. Используя эмулятор QEMU, они запустили минимальный модуль hello.erl, который вызывает встроенную функцию erlang:halt/2 с кодом возврата 42. Это подтвердило работоспособность базовой цепочки: загрузка BEAM, инициализация JIT, компиляция и выполнение кода.

JIT инициализирует общие фрагменты кода и модуль erts_beamasm, содержащий критические инструкции для управления процессами, такие как run_process и normal_exit. Модуль hello был помещён в предзагружаемые модули, чтобы обеспечить его выполнение при старте системы. Код доступен в репозитории GitHub, а работа ведётся при поддержке Erlang Ecosystem Foundation.

• Обсуждение причин разработки JIT-компилятора для ARM32 в Erlang, включая актуальность 32-битных ARM-микроконтроллеров на рынке встроенных систем.
• Дебаты о текущем статусе архитектуры ARM32: участники отмечают, что она не устарела и до сих пор поддерживается в новых реализациях (v8-a, v8-m), несмотря на её нишевый статус.
• Вопросы о целесообразности запуска Erlang на маломощных устройствах: одни видят потенциал, другие сомневаются в необходимости из-за ограничений памяти и производительности.
• Обсуждение технических деталей: путаница с ESP32 JIT, сравнение с RISC-V, особенности наборов инструкций (Arm/Thumb/Thumb2).
• Замечание о том, что «более высокая скорость» других языков является субъективной характеристикой («при определенных определениях быстрее»).

Каталог WeUseElixir собирает реальные примеры использования языка Elixir в продакшене, демонстрируя разнообразие его применения — от библиотек до крупных компаний. Здесь можно найти такие известные инструменты, как Oban для обработки фоновых заданий, Absinthe для работы с GraphQL и Flop для пагинации в Ecto.

Среди компаний, применяющих Elixir, — PepsiCo, платформа для стриминга концертов VEEPS и сервис удалённой работы Remote. Каталог помогает разработчикам находить вдохновение, инструменты и потенциальных работодателей, подчёркивая практическую ценность экосистемы Elixir.

• Участники высоко оценивают язык Elixir, его подход к функциональному программированию, параллелизму и сообщество, отмечая его эффективность для проектов любого масштаба.
• Были предложения по улучшению каталога WeUseElixir: добавить фильтрацию по типам проектов, разрешить добавлять компании без регистрации и исправлять данные о стеках технологий.
• Обсуждались технические аспекты: преимущества BEAM (виртуальной машины Erlang) для отказоустойчивости, продуктивность фреймворка Phoenix LiveView и варианты интеграции с клиентским состоянием.
• Участники поделились известными компаниями и проектами, использующими Elixir (например, Plausible Analytics, Supabase, ElectricSQL), и другими подобными каталогами.
• Задан вопрос о выборе между языками экосистемы BEAM: Erlang (для опытных команд), Elixir (общего назначения) и Gleam (строгая типизация).

Блог asciinema

• Начало работы
• Исследовать
• Форум
• Нанять меня!

3.0 Опубликовано 15 сен 2025, Марчин Кулик

Рад объявить о выпуске asciinema CLI 3.0!

Это полная переписывание asciinema на Rust с обновлением формата файлов записи, добавлением live-стриминга терминала и множеством улучшений.

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

Переписывание на Rust было сделано из-за моего предпочтения этого языка перед Python для работы с системными вызовами и параллелизмом. Это привело к ускорению запуска, упрощению установки (статический бинарник) и интеграции виртуального терминала asciinema.

Формат файла asciicast v3

Новый формат asciicast v3 использует интервалы времени вместо абсолютных временных меток, что упрощает редактирование записей. Заголовок был реструктурирован, добавлена поддержка события выхода ("x") и комментариев через #.

Пример записи:

{"version": 3, "term": {"cols": 80, "rows": 24, "type": "xterm-256color"}, "timestamp": 1504467315, "title": "Demo", "env": {"SHELL": "/bin/zsh"}}
[0.248848, "o", "Hey Dougal...\n"]
[0.248848, "o", "Yes Ted?\n"]
[1.001376, "o", "Is there anything on your mind?\n"]
[3.500000, "m", ""]
[0.143733, "o", "No."]
[2.050000, "r", "90x30"]
[1.541828, "o", "Bye!"]
[0.8870, "x", "0"]

Формат уже поддерживается сервером и плеером asciinema.

Live-стриминг терминала

Новый CLI позволяет транслировать сессии терминала в реальном времени с двумя режимами:

• Локальный режим использует встроенный HTTP-сервер для просмотра в доверенных сетях
• Удаленный режим публикует поток через сервер asciinema с shareable URL

Примеры:

$ asciinema stream --local
::: Live streaming at http://127.0.0.1:37881

$ asciinema stream --remote  
::: Live streaming at https://asciinema.org/s/TQGS82DwiBS1bYAY

Плеер asciinema поддерживает адаптивную буферизацию для плавного воспроизведения. Сервер может записывать live-стримы, хотя на asciinema.org эта функция временно отключена.

Локальный приоритет

Ранние версии asciinema автоматически загружали записи на asciinema.org. Теперь CLI позволяет сохранять записи локально в файл формата asciicast v1 с выбором публикации или локального хранения.

• Участники высоко оценили Asciinema, особенно за простоту использования CLI, высокое качество GIF и новую функцию live-стриминга терминала.
• Было отмечено, что сервис, несмотря на высокую нагрузку, стабильно работает всего на двух маломощных виртуальных машинах (2 ГБ RAM каждая), что демонстрирует эффективность Elixir/Phoenix и BEAM.
• CLI-часть утилиты была переписана на Rust, что также было воспринято положительно.
• Некоторые пользователи выразили пожелания, такие как нативная поддержка экспорта в SVG/GIF и встроенные инструменты для скрытия секретов в записях.
• Обсуждались возможные сценарии использования live-стриминга, в том числе для стриминга программирования без дополнительного оборудования.

Первые впечатления о Gleam

Ищу новый язык для изучения и выбрал Gleam — это «эликсир» со статической типизацией.
Чтобы понять, подойдёт ли он, решил переписать старый pet-project: парсер логов AIM 1999-2007 гг.
Формат простейших логов — plain-text:

Session Start (DumbAIMScreenName:Jane): Mon Sep 12 18:44:17 2005
[18:44] Jane: hi
[18:55] Me: hey whats up
Session Close (Jane): Mon Sep 12 18:56:02 2005

Цель: вытащить только тексты сообщений, потом добавить метаданные и веб-интерфейс.

CLI-аргументы

Стандартной библиотеки для argv нет.
Сторонний пакет argv решает задачу в 4 строки:

case argv.load().arguments {
  [path] -> io.println("arg: " <> path)
  _      -> io.println("Usage: gleam run <dir>")
}

Компиляция

gleam build собирает проект, но исполняемого файла не создаёт.
В build/dev/erlang/... появляются .beam-файлы — байт-код для BEAM-ВМ.
Запускать удобнее через gleam run.

Парсер

Начал с теста: функция принимает многострочный текст и возвращает список сообщений.

plaintext_logs.parse(log)  
|> should.equal(["hi", "hey whats up"])

Дальше — добавлю структуру Message {time, author, text} и разберу XML/HTML-логи.

• Gleam: маленький, строго типизированный FP-язык на BEAM; хвалят простоту, TEA/actor-модель и устойчивость к ошибкам.
• Главный минус — нет трейтов/интерфейсов и приходится подключать внешнюю библиотеку для акторов.
• Кто-то хочет LLVM-бекенд вместо BEAM, но большинство считают BEAM лёгким, масштабируемым и почти незаменимым для конкурентных задач.
• Парсинг: комбинаторы удобны, но медленны без оптимизирующего компилятора; в Gleam чаще используют pattern-matching и пакет splitter.
• Экосистема молода: библиотек мало, LLM плохо знают язык, но interop с Erlang/Elixir уже работает.

GRiSP – три стека для запуска Erlang/Elixir на встраиваемых системах:

• GRiSP Metal – BEAM на RTEMS, 16 МБ ОЗУ, реальное время, прямой доступ к железу.
• GRiSP Alloy – BEAM на Buildroot-Linux RT, несколько VM, приоритеты и привязка к ядрам.
• GRiSP Forge – то же, но на Yocto, для долгих жизненных циклов и кастомных BSP.

GRiSP-io – облачная платформа для OTA-обновлений, мониторинга и масштабного управления устройствами.

Преимущества: открытый код, надёжность BEAM, минимальные задержки, масштабируемость от прототипа до флота.

GitHub | GRiSP.io

• Участники спорят, считать ли 16 МБ «MCU-классом»: традиционные микроконтроллеры имеют ≤1 МБ, но современные ESP32 и NXP i.MX 6UL уже выходят за эти рамки.
• GRISP — это BEAM-платформа поверх RTEMS для «мягкого» реального времени, в отличие от Nerves (BEAM на минимальном Linux).
• Пользователи отмечают удобство модели акторов и горячей замены кода, но сомневаются в приоритетах процессов и строгих гарантиях latency.
• Для устройств с КБ-объёмом памяти предложили AtomVM; 16 МБ пока выше среднего, но быстро дешевеет.
• На «железе» 90-х Erlang/Elixir запустится, если ОЗУ ≥16 МБ; сама BEAM требовала ещё меньше.

Задача
Лондонское агентство Strand ведёт сотни маркетинг-проектов в год. Финансовый учёт раньше велся вручную через таблицы. В 2020 г. команда из трёх разработчиков запустила прототип финансовой системы; он быстро стал критически важным, и потребовалось обеспечить надёжность и простоту поддержки при минимальных ресурсах.

Решение
Strand выбрал язык Gleam на платформе BEAM:

• Безопасность: чистый код не падает; сбои внешних сервисов изолируются лёгкими процессами.
• Практичность: язык мал, однозначен, осваивается за день; доступны 40 лет библиотек Erlang/Elixir.
• Опыт разработки: единый пакет с форматтером, автодополнением и понятными ошибками; сборка мгновенная.

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

• Вероятно, языки вроде Gleam выиграют у ИИ благодаря строгой типизации и быстрой обратной связи.
• Некоторые новички застревают в «абстракционном аду» и советуют сначала освоить Erlang/Elixir.
• Производственные истории успеха Gleam на BEAM вдохновляют.
• Однофайловые исполняемые файлы можно собрать через компиляцию в JavaScript + Node SEA или Burrito, но полноценный VM-free релиз пока нет.
• Качество примеров и стабильность языка становятся важнее их количества для LLM.
• Чистые, референциально прозрачные языки удобны ИИ для параллельного тестирования блоков кода.

Elixir-миф #1: «Let it crash»

Фраза «let it crash» вводит в заблуждение: звучит так, будто приложение падает, хотя речь всегда идёт об отдельном процессе, который супервизор мгновенно перезапустит. Приложение при этом живёт.

Проблема: процессы связаны с реальными вещами — сокетами, HTTP-запросами, файлами, БД. Пример LiveView:

def handle_event("import_data", %{"data" => data}, socket) do
  Enum.each(data, &create_item/1)
  {:noreply, socket}
end

Код упадёт, если:

• имя события не совпадёт;
• нет ключа "data";
• data не список;
• ошибка в create_item/1.

Первые три случая — скорее баг фронтенда, падение допустимо. Но последний — ошибка валидации одного элемента, и из-за неё весь веб-сокет пользователя рвётся, UI пропадает. Это плохой UX.

Что делать вместо «let it crash»

1. Валидируй вход до бизнес-логики.
2. Возвращай ошибки пользователю, а не падай.
3. Перезапускай только то, что действительно сломалось (например, соединение с БД), а не весь контекст пользователя.

Слоган лучше переформулировать:
«Не позволяй падать — позволяй исцеляться».

• «Let it crash» — это не призыв игнорировать ошибки, а концепция быстрого восстановления через дёшёвые процессы и деревья супервизоров BEAM.
• Слоган выглядит провокационно, но подразумевает, что система спроектирована так, чтобы падение одного процесса не рушила всё приложение.
• Ключевой источник — докторская диссертация Джо Армстронга «Making reliable distributed systems…», которую участники считают обязательной к прочтению.
• Перезапуск не решает фундаментальные проблемы (отсутствие конфигурации и т. д.), но помогает с транзиентными сбоями и временными условиями.
• Если ошибка повторяется, дерево супервизоров поднимает её всё выше, пока приложение либо восстановится, либо окончательно упадёт.