Автор рассказывает, как он создал свой собственный класс AppVersion для сравнения версий, но затем обнаружил, что в Ruby уже есть встроенный Gem::Version, который делает то же самое, но лучше. Он заменил свой класс на встроенный и призвал сообщество делиться знаниями, чтобы избежать изобретения велосипедов.

• Участники восхищаются элегантностью и лаконичностью Ruby, особенно в реализации классов вроде AppVersion, и отмечают его выразительность по сравнению с TypeScript, Elixir и другими языками.
• Подчеркивается мощь метапрограммирования Ruby и его роль в развитии любви к программированию, хотя есть критика по поводу документации и экосистемы.
• Сравниваются реализации AppVersion в других языках (Python, Java, Scala), где признается сходство в выразительности, но отмечаются различия в синтаксисе и подходах.
• Упоминается ностальгия по Rails и его современное состояние, а также скрытые возможности стандартной библиотеки Ruby.
• Есть критика Ruby за "скрытые опасности" (footguns) и проблемы с масштабированием, а также за то, что экосистема Rails затмевает сам язык.

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

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

• Пользователь случайно обнаружил сбой в регионе компании во время тестирования Elixir + Phoenix LiveView.
• Проблема затронула Docker Hub и другие сервисы, что вызвало вопросы о перемещении Snapchat из GCP.
• Коллеги отреагировали с юмором, упомянув предстоящие внутренние расследования и сложности локального тестирования.
• Появились шутки о возможной причине сбоя, связанной с ИИ.

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал Phoenix LiveView. Вместо того чтобы разделять фронтенд и бэкенд на разные стеки, он нашёл решение, которое позволяет писать всё на одном языке — Elixir. Это не только ускоряет разработку, но и даёт серьёзные преимущества в производительности.

Ключевые моменты:

• Меньше кода, меньше ошибок: Вместо двух кодовых баз (например, JavaScript + PHP) всё пишется на Elixir, включая UI-логику, что снижает вероятность ошибок.
• Реальное время без усилий: LiveView использует WebSockets для двухсторонней связи в реальном времени, что встроено "из коробки" и не требует дополнительных библиотек.
• Производительность и надёжность: Бэкенд на Elixir (работающем на Erlang VM) обеспечивает высокую конкурентность и отказоустойчивость. Фоновые задачи через Oban перезапускаются автоматически при сбоях.
• Единая архитектура: Нет необходимости в отдельном API или SPA, что упрощает разработку и развертывание.

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

• Обсуждение в основном вращается вокруг сравнения Rails, Phoenix и LiveView, но при этом всплывают факты, что Rails всё ещё умеет WebSocket, а Phoenix не так уж идеален, если нужен только CRUD-приложение.
• Участники спора подчеркивают, что выбор стека часто диктуется личными предпочтениями и опытом, а не объективными преимуществами.
• Несколько раз поднимается тема, что современные фреймворки всё ещё не решают проблему масштабирования и фоновых задач, и что важнее выбрать тот стек, который действительно подходит под задачу.
• Также обсуждается, что выбор инструмента влияет на набор библиотек и сообщество вокруг него, и это может быть важнее, чем абстрактные преимущества языка.

Выпуск Elixir v1.19 принёс важные улучшения в области типизации и компиляции. Теперь компилятор способен выводить типы для всех конструкций, включая случаи, где раньше требовались аннотации. Это позволяет, например, определить, что функция even? возвращает boolean(), даже если она определена без явных ограничений типов.

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

Наконец, улучшена проверка типов при работе с протоколами: если раньше передача неподдерживаемого типа в string interpolation или другой полиморфный контекст могла пройти незамеченной, то теперь компилятор укажет на проблему и предложит возможные решения. Это касается как вызовов, так и реализации протоколов.

• Elixir продолжает стабильно выпускать улучшения без крупных breaking changes, чего не скажешь о большинстве языков.
• Дискуссия показала, что у Elixir уже есть типы (структуры, Dialyzer, TypedStruct), а новые фичи лишь улучшают DX, не требуя отдельного "TypeScript-режима".
• Несколько участников поделились опытом: кто-то бросил работу ради возможности писать на Elixir, кто-то отметил, что стек-трейсы в продакшене выглядят как Erlang, но это редкость и обычно стектрейсы читаемы.
• Поднят вопрос о том, что если язык развивается так стабильно, то почему бы не попробовать его в новом проекте, даже если ты не используешь его на работе.

VALORANT изначально требовал серверы с частотой 128 тиков для минимизации преимущества атакующего и обеспечения честного геймплея, где защитники успевают реагировать. Это означало обработку кадра каждые 7,8125 мс, но изначально сервер тратил 50 мс на кадр, что делало задачу масштабирования неподъёмной из-за высоких затрат на CPU.

Команда разбила проблему на категории: репликация, сеть, анимация, движение и другие, внедрив систему ValSubsystemTelemetry для точного измерения времени выполнения кода. Используя внутреннюю аналитическую платформу Riot, инженеры визуализировали данные и последовательно оптимизировали код, железо и настройки ОС, достигнув цели в 2,34 мс на кадр и обеспечив бесплатные 128-тиковые серверы для всех игроков.

• Обсуждается высокая частота обновления (128 тиков/секунда) серверов Valorant в сравнении с другими играми (Factorio 60, Minecraft 20, CS:GO 64, Fortnite 30).
• Поднимается вопрос архитектурных решений и оптимизаций для достижения низкой задержки (<35 мс), включая выбор процессоров Intel Xeon и отключение анимации в фазе покупки.
• Критикуется система "sub-tick" в CS2 как менее эффективная по сравнению с классическим высоким тикрейтом, а также современный matchmaking, не учитывающий пинг.
• Упоминается, что для некоторых жанров (например, Runescape) достаточно низкого тикрейта (0.6 в секунду), и это определяет геймплей.
• Обсуждаются технические сложности реализации высокопроизводительных серверов на языках с GC (Erlang, Elixir) и предпочтение C++ для симуляции игры.

Каталог 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-стриминга, в том числе для стриминга программирования без дополнительного оборудования.

Делай вклад в цифровые общественные блага

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

Проект	Язык	Направление
mautic	PHP	маркетинг-автоматизация
credebl	TypeScript	децентрализованная идентичность
avni-webapp	JavaScript	медицинские данные
the-turing-way	TeX	воспроизводимая наука
X-Road	Java	обмен данными между госорганами
OpenTermsArchive	JavaScript	прозрачность сервисов
OpenFn Lightning	Elixir	автоматизация workflow
android-fhir	Kotlin	мобильная медицина
casa	Ruby	волонтёрство для детей
ODK Collect	Kotlin	сбор данных в поле
cht-core	JavaScript	цифровое здравоохранение
policyengine-app	Jupyter	расчёт последствий политик
querido-diario	Python	открытые госгазеты
ODK Central	JavaScript	сервер для форм
decidim	Ruby	участие граждан

Фильтр по языку и Целям устойчивого развития (SDG) на сайте.

• Участники приветствуют инициативу списка проектов с «good first issue», но сомневаются в кураторстве: много проектов без активных задач, не все связаны с социальным влиянием.
• Предложено скрывать репозитории с 0 issues и добавлять метрики активности (коммиты, разработчики, возраст), как в Re-Decentralise.
• Новички спрашивают, считать ли правку опечаток «настоящим» вкладом; большинство советует упоминать, но честно указывать уровень участия.

Первые впечатления о 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 уже работает.

• Async в Python уже 10 лет, но до сих пор не стал мейнстримом.
• Причины:
  • ошибки «забыл await», трудно отлаживать;
  • GIL приучил не думать о параллелизме;
  • польза только при I/O-задачах, CPU-нагрузка не ускоряется;
  • фреймворки не догнали: Django ORM всё ещё синхронен, Flask тоже.
• Классический кейс — HTTP-запросы: стартуем сотни корутин, ждём ответов, не блокируем интерпретатор.
• Но дисковый I/O, CPU-задачи и другие сценарии не так выигрывают.
• Вывод: чтобы новые фичи 3.14 (free-threading, sub-interpreters) не повторили судьбу async, нужно:
  • чётко объяснять, какие задачи они решают;
  • давать простые API и инструменты отладки;
  • не ждать, пока экосистема «догонит», а сразу внедрять в популярные библиотеки.

• Async в Python пришёл «слишком поздно»: к моменту появления asyncio большинство уже решали задачи I/O через forking, multiprocessing или сторонние библиотеки.
• «Цветные функции» и необходимость переписывать весь код ради async делают его «заразным» и несовместимым с существующими синхронными библиотеками.
• Сложная семантика (event-loop, await, cancellation-исключения), плохая документация и отсутствие понятных best-practice усложняют отладку и поддержку.
• Для большинства задач Python-разработчика async не критичен: WSGI/WSGI-совместимые решения, Celery, Kafka и простое горизонтальное масштабирование покрывают потребности.
• Альтернативы (trio, anyio, gevent) и другие языки (Go, 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 требовала ещё меньше.

V как Go с шоколадкой
Go — это ваниль: просто, быстро, без фанатизма. V же — «ваниль++»: тот же вкус, но сверху посыпка из фич.

Карты

langs := {"elixir": {"score": 100}}
score := langs["elixir"]["score"] or { -1 }

Фиксированные типы, or {} вместо if err != nil, spread-оператор ... для слияния.

Структуры

struct Language {
pub mut:
    score int = -1
    name  string @[required]
}

Методы можно вешать прямо на массивы, поля можно помечать @[required], дефолты и флаги CLI задаются в одном месте.

WithOption

fn new_server(opts ServerOptions) ! { ... }

Встроенный «функциональный» паттерн: new_server(port: 8080, debug: true).

Enum и лямбды

Enum’ы есть, лямбды короткие: nums.filter(it % 2 == 0).

Подводные камни

• net.http пока не дотягивает до Go.
• veb (веб-фреймворк) сырой.
• Сборка сложнее: нужен v и C-компилятор.
• Параллелизм есть, но экосистема молода.

Итог

V — это Go с синтаксическим сахаром и парой острых углов. Для экспериментов — огонь, для продакшена — пока нет.

• Участники спорят, действительно ли V лучше Go: одни отмечают быструю компиляцию и «красивые» фичи, другие — нестабильность компилятора и отсутствие надёжности.
• Поддерживающие Go указывают на его зрелость, стабильность GC, удобство кросс-компиляции и отказ от «лишнего».
• Сторонники V хвалят синтаксис (const по умолчанию, sum types, простой С-интерфейс), но признают, что язык пока «сырой».
• Некоторые считают V «предупреждением» о том, почему Go часто говорит «нет» новым возможностям.
• Есть мнение, что ни Go, ни V не решают задачу «лёгкого C для приложений»; предлагают смотреть на Zig или Free Pascal.

Официальный сервер Elixir по протоколу LSP
Репозиторий elixir-lang/expert содержит реализацию Language Server Protocol для языка Elixir.

• Цель — обеспечить редакторам и IDE полную поддержку Elixir: автодополнение, навигация, рефакторинг, диагностика.
• Архитектура — сервер написан на самом Elixir, использует GenLSP для обработки JSON-RPC сообщений.
• Функции
  • анализ кода в реальном времени через mix compile --warnings-as-errors;
  • подсказки по типам и документации из @spec и @doc;
  • поиск определений и ссылок по всему проекту;
  • форматирование через mix format;
  • встроенный отладчик и поддержка IEx.
• Установка — добавьте зависимость {:expert, "~> 0.1"} в mix.exs или установите плагин для VS Code / Vim / Emacs.
• Вклад — принимаются PR и issue; следуйте гайду CONTRIBUTING.md.

• Новый LSP «Expert» — результат объединения усилий всех существующих реализаций (ElixirLS, Lexial, next-ls).
• Архитектура продумана до мелочей: поддержка разных версий языка и защита пространств имён приложений.
• Название «Expert» вызвало споры: кто-то считает его высокомерным, кто-то — забавным и в духе экосистемы.
• Это первый «официальный» LSP под эгидой elixir-lang, но без постоянного участия core-команды.
• MCP напрямую не поддерживается; для LLM-контекста рекомендуют TideWave.

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

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

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

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

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

Tidewave Web – агент для Rails и Phoenix, работающий прямо в браузере.
Он видит текущее состояние UI, знает структуру проекта и выполняет код в вашем окружении без переключений между инструментами.

Основное

• Общий контекст – кликните по элементу, скажите «добавь кнопку экспорта CSV»; Tidewave сам найдёт шаблон, контроллер и модель.
• Глубокая интеграция – запросы к БД, логи, документация, тесты в браузере.
• Установка – добавьте gem/пакет, откройте /tidewave, подключите GitHub Copilot или Anthropic.
• Цена – 20 сообщений в месяц бесплатно; Tidewave Pro – $10/мес.

Ограничения

• Лучше всего работает с полноценными Rails/Phoenix.
• React/Vue пока не поддерживаются (в планах).
• Django, Flask, Next.js – в листе ожидания.

Планы

TODO-списки, суб-агенты, React-поддержка.
Присоединяйтесь к Discord или форме ожидания.

• Tidewave — это инструмент для «живого» редактирования Phoenix/Rails-приложений прямо в браузере: LLM видит DOM, шаблоны, тесты и может менять код на лету.
• Следующие шаги: React-интеграция, затем Python/JS-фреймворки; уже можно записаться в wait-list.
• Часть пользователей в восторге («не мог мечтать о таком»), другие не понимают преимущества перед Claude Code или MCP-серверами.
• Главный плюс, по словам Jose Valim — глубокая связь с конкретным фреймворком: LLM точно знает, какой шаблон сгенерировал элемент, и может запускать код без угадывания.
• Платная модель: используются ваши ключи Copilot/Anthropic, но после лимита нужно платить Tidewave (часть трафика идёт через их сервер).
• Пока нет поддержки локальных LLM (Ollama) и HTTPS-проблемы у некоторых команд; Jose просит писать в Discord для отладки.

Быстрый старт

Библиотека flow отделяет бизнес-логику от развёртывания: топологии, исполнения, обмена сообщениями, жизненного цикла, мониторинга и обработки ошибок.

step-fn и процессы

Логика описывается функциями step-fn, которые flow заворачивает в процессы, крутящиеся в цикле. step-fn не работают с каналами напрямую и не хранят состояние, поэтому легко тестируются и переиспользуются.

step-fn имеет четыре арности:

describe (step-fn) → descriptor

Возвращает статическое описание :params, :ins, :outs — карты имя → документация. Имена входов и выходов не должны пересекаться.

{:params {:size "Максимальный размер"}
 :ins    {:in  "Входной канал"}
 :outs   {:out "Выходной канал"}}

init (step-fn arg-map) → init-state

Один раз вызывается при старте процесса; превращает параметры из flow-def в начальное состояние.

transition (step-fn state transition) → state'

Вызывается при переходах жизненного цикла (::flow/start, ::flow/stop, ::flow/pause, ::flow/resume). Используется для управления внешними ресурсами.

transform (step-fn state input msg) → [state' {out-id [msgs]}]

Вызывается для каждого входящего сообщения. Возвращает новое состояние и карту выходных сообщений. Выход может быть пустым, но каждое сообщение — не nil. Исключения логируются в :error-chan.

Состояние процесса

Карта с любыми ключами. Дополнительно:

• ::flow/pid — идентификатор процесса
• ::flow/in-ports, ::flow/out-ports — карты cid → внешний канал (создаётся в init)
• ::flow/input-filter — предикат cid для фильтрации входных каналов

Хелперы

• lift*->step — из f(x) → coll делает step-fn с одним входом и выходом
• lift1->step — то же, но f(x) → single-value
• map->step — из карты с ключами :describe, :init, :transition, :transform строит step-fn

Запуск процесса

Функция process принимает step-fn и опции:

• ::workload — :mixed, :io, :compute
• :compute-timeout-ms — таймаут для :compute (по умолчанию 5000 мс)

• Участники обсуждают, жив ли Clojure: сообщество стабильно, но менее хайповое; NuBank расширяет core-команду и нанимает Developer Advocate.
• core.async.flow предлагает декларативный, фиксированный граф каналов для «структурированной конкурентности»; ошибки и паузы можно отслеживать, но изменять топологию на лету пока нельзя.
• Сравнивают с GenStage (Elixir), Manifold, Trio и missionary/electric; можно использовать как OS-, так и green-потоки.
• JVM-тулчейн вызывает у новичков страх, но Leiningen/deps.edn упрощают работу, а отладка всё же возможна.
• Clojure-окосистема активно развивается: Babashka, XTDB, Dyna3 и другие проекты; язык недавно получил мажорный релиз и готовится к виртуальным потокам JVM.

%PDF-1.3  
5 0 obj  
<< /Length 737 /Filter /FlateDecode >>  
stream  
xڵUKO0WHc;>@b% eiEд;~4PV\\V=رy|̸0q"e\\%\*H-YD 9Ze2& Őg¨Ҡ3D=>mErX\\/ )=9>8IrA3H³J
>\['\[R{89CRԿ8EXDMkUĿKRcRIX|m8vcM"mc-jjb|4ӍYJ+{A=4e16}{gρ\`sa(w 1}@+\\\\
pȜc5AKt!}'n\\\[M8pe$ZQdP\`N\]͚Lۛ쨣Hg6GsBxfܱ ?jQ<
ߵT
{P̯?c)n\[y%̲OprN5~qxvHrz:T:vT7Q Iɩw4fQ+8V\[ %ͅt-x^\]z\]>ä́^ukK!zvXh#O&gCT fqkk5  
endstream  
endobj  

4 0 obj  
<< /Type /Page /Contents 5 0 R /Resources 3 0 R /MediaBox \[0 0 595.276 841.89\] /Parent 12 0 R >>  
endobj  

1 0 obj  
<< /Type /XObject /Subtype /Form /FormType 1 /Matrix \[1 0 0 1 0 0\] /BBox \[0 0 143 73\] /Resources << /ProcSet \[ /PDF \] /ExtGState << /R8 13 0 R /R4 14 0 R >> >> /Length 15 0 R /Filter /FlateDecode >>  
stream  
xYn-;mVzn2
#m@sǀ\\R#E?ſ߿GJm>k?kZ\_cߏҾv>K~Rr~>8J?3x>jK\_cxy+e\*o뫔/|篲g=|jv~PUOWW9K<+;><c϶\_kQZag<xk쉳q?(w ֝ Ip\_\`; }T?q\_ugnkQy߹uei<qw;a=pL\]'j\*#@=k5BLv~&4<yyZ:1y!&F|@yQU,8} 7q=6Aݶ\*g95\]\\T7Ky1PO9yb~nw.ڸQ~QzP· DZs«rUC\] 0C!K83{0\\ЮѪ\]C!S s+B/qҺsCrvks6}MYX=HPпC<Ӈs3?3Ϸa!9OM·ΎXŞ8׉|h'湻.3>-C @:k1>@y˹C\*X>p"ۂ @owԩv!X8a5-z-:Ʋyӛ2=;d\*繲9oAkY\_;,,=ᰐ3>R;"8l=ׄ>@>xݞ\\FyV!vY\]1w1ޘML9JJv9&#qzGmr>9E/ϓdྟ\_ov9, \]:$玚"#jyH灈Dsd@f"T~Gf\[tV">Ɵ
Wћňq\[qJ\[$V,KD)Q!xg\\ܚtpv7ҘBudm.$0#HKg8G  V5lC/u9 l{ihs
9C ;ajB٪> t|^P4vfAu$F0P ʥ.hDA9GyhȑtR 7 ښ^՟66:lĕ׮b<Ү.$Jɻ(Ʋ~hAόBs~Q^|j9Xꂥ.~u:,%MT(zϰL:"(:t4݇/vk|eQq}t%I9jBY9L9\]N& #QK;bggwcYjUh\\PM8-Z%d3x~خ"+,Π£n zo~?^'-BZ}C0^bUq\[$"Jދ鳣&mu(0AP/dm{ę3>rP1-$$2đ7;TƃAg\\R$1#) mh 3~.b8fK'C/x9#
\*N,}v89\`
sb3\`8 \[S\*7g,v?3?ܷ ʾJ \[A?tSKBs\`y$Xu4ٟ|
HdoܥfaDX%39.L=a\*0 #RnI0葡L&u;Ce+JMI\_Z^8tT0wJ#g|q2!3mԹ3"O~e;,D)Rı΅P# \[@y/.ϹG6s:t? eMf,\_B;PAXHG뇫b/+D<cflI.:eLט/l'B-HR \]$agra;{9rrs;UPymX4)iEf㕇qjS(;bedȑLtˆ &>߫HŖ)8퇀ˡeGA 9ݹ.\_U(61,%#t$gC&ʄ+SA)SHݍ\_NE%d̨
R΀Zpf ?dAH,͜c\*g(|@'13sdg\]\[Lw"{"hx<.#ob@E4$ i=ǃ࿦4#{,<Y f^a&mVFS$dG2 hAB:Z{Q\_F т1>P$9PA<X{TdMBt=\\{9=CvOtO&E^
JwM6'\]!9V|rɟTEyQX/> -|0&u$)i5,yץ}ceCGw\_ړm$)5 |>s"dؒdthjziYF%\\~ˤyKΈ+bK0g\\qtOT%,\*\_\\~9pϊBpCkB+@$\_s}Op^5efJDM\]-n. p)Rd7>Od0 \`J7Dmbs}t|)\`n3h\[V!ueX Cװd\`~>G:EͰ6q@cvKl |6\`ldwBÉo T=Iiw#Ar#tV:ܒA\`;\_J\`樼:4{OSH!H8!
c3vavg{rmS<3,r8!UD0^0 1\`\`Nz\`{ſb$R\`wZ5~9kf\*OpZ |=,
w$M x%;L%6R\_ :BYqOHRŬ.sw5g+
(%h1y6\*kyVES\]@E,;DFxKY1oEnSeKz&Ƙ':rxwEb1\\!^pX\]=}2x7\_^v+\*~EU;A9-
IIKTP,c(0v4@,8f qIwy-<@!Yg Վ.S4 2E\]AgG<dXY3<9\_5U>2|kӏ4—^\[Gbڗa@h<)Y&\*bpG'td:\*o}탌Otda 2hyL\\Xdif\\ۀ-ZS#2 &
h\\Yo~!7z8 LuÅCP\]k?}C0 F>Jз;,) Qb\[:ӬT\_n@@!=\`5^/Ed/pveU&lB؂>TVD-r3: \]pLE@lvIMd5Q{yœܰ'T~a
 >x @u\\8qhjqc 7 E \*\]Jʭ\`(2/ W%Wi:=PRB,+$ >;9HR\[,fßfRDʽdmܺ/<y
E%<{׌8@Hшxvi}ό\_HEE-"-XJt6m}Fn{~
gӼgŌ0~s|kW|b4wH5ﱥמo ڵ7JH@~(abe3Ы-nWNjNR1,dg|LBq+&\*BWiƥԕBJiʲcؽkl➱7&x\\B 5q.9:\]mRף>aFybU{r@׌aR=B~Q2p\\kRgƻ}2aax\`5Vq4\[0?&G'K$\[TѸQv&xZ Y/ឨ {^zVE\\̵Pp\] O;5k-5C+ 1.p{|do@սV,L>{X&ևɓB|CR
/\*3>.sMX!G!P(8Z/ 
o}X< K)!?'Jx-->c TAi\_""GAyK~yw낇35>yR#?Grig\\3  ·0\\,sE 'Ss,GP83nbby@zqy\[@gL>+?O(hX={UL;m dI! FMV70\[w\_fW+E1sxbP,#\[BWpo\*I\[b"򉒽kD,?zoqr{BC-礌\*Y!Ԫ\*96͑k.?Ŕ(%z,MJйL0A:/{<+b<,@W>PmEkxX<bLqSDZMY=êbOÚֈsAe8CTuv
Yq\]Ѷ7pp 4
' =LLo@xĸ?AӝEVXEaԲ5

• Участники вспоминают Джо Армстронга и его ссылки на работу Джима Грея о Tandem.
• Отмечают, что Erlang/Elixir были технологически опережающими, но не стали массовыми.
• Идеи Erlang постепенно проникают в .NET и Java через Akka и Orleans.
• Удивляются, почему Erlang не используется даже в новых коммутаторах Ericsson, хотя был создан для них.
• Считают, что полное внедрение Erlang угрожает существующим бизнесам и рабочим местам, а рынок предпочитает «хуже, но дешевле».

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…», которую участники считают обязательной к прочтению.
• Перезапуск не решает фундаментальные проблемы (отсутствие конфигурации и т. д.), но помогает с транзиентными сбоями и временными условиями.
• Если ошибка повторяется, дерево супервизоров поднимает её всё выше, пока приложение либо восстановится, либо окончательно упадёт.