Hacker News Digest

Автор рассказывает о своем пути к любви к Erlang, начавшегося с непонимания базовых концепций программирования в восемь лет, когда столкнулся с выражением "X = X + 1" в BASIC, показавшимся ему математической ложью. В университете он столкнулся с такими же трудностями при изучении C, но продолжил учиться через практику и эксперименты. Переломный момент наступил, когда партнер по бриджу спросил, как суммировать числа от 1 до 10 без циклов, что привело его к открытию рекурсии в Prolog — математически чистого подхода, где описывалось "что" является, а не "как" вычислять.

Знакомство с Erlang произошло случайно на турнире по бриджу от шведского игрока, который описал его как функциональный язык для распределенных, отказоустойчивых систем. Автор был поражен возможностью простого обмена сообщениями между разными узлами без сложных протоколов, демонстрируя пример ping-pong на Erlang. Этот язык, сочетающий функциональность, распределенность и отказоустойчивость, стал тем, что он искал с детства — способом программирования, где математика говорит правду.

• @az09mugen отмечает полезность функции > cd .. в конце статьи за простоту и мобильную доступность.
• @az09mugen предполагает наличие пасхалки (easter egg) в этой функции.
• @Gleamball выражает благодарность за выступление и обмен информацией.

Wren — это маленький, быстрый, объектно-ориентированный скриптовый язык с поддержкой concurrency. Его реализация занимает менее 4000 строк кода, что позволяет изучить весь код за один день. Язык сочетает в себе идеи Smalltalk, Lua и Erlang, предлагая современный и понятный синтаксис. Wren использует быстрые однопроходный компилятор в байт-код и компактное представление объектов, что позволяет ему конкурировать с другими динамическими языками.

Особенностью Wren является акцент на классах как основной парадигме и встроенная поддержка легковесных волокон (fibers) для организации программы в набор взаимодействующих корутин. Язык создан для встраивания в приложения — он не имеет зависимостей, имеет небольшую стандартную библиотеку и простой C API. Wren компилируется как C99, C++98 или более новые версии, доступен для запуска в браузере и открыт на GitHub под руководством Боба Нистрома.

• Wren — язык, который сочетает в себе лаконичность Lua и объектно-ориентированный синтаксис, но при этом остаётся компактным и легко встраиваемым.
• Пользователи отмечают, что Wren легко встраивается в C/C++ проекты, но при этом не требует сложных зависимостей, что делает его привлекательным для встраиваемых скриптовых языков.
• Некоторые участники обсуждения упоминают, что Wren может быть использован как альтернатива Lua, особенно в контексте встраивания в игровые движки и другие приложения.
• Обсуждается также, что Wren имеет активное и дружелюбное сообщество, что способствует его развитию и поддержке.

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

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

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

Разработчик сравнивает несколько популярных фреймворков и объясняет, почему выбрал 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, но это редкость и обычно стектрейсы читаемы.
• Поднят вопрос о том, что если язык развивается так стабильно, то почему бы не попробовать его в новом проекте, даже если ты не используешь его на работе.

Команда 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).
• Замечание о том, что «более высокая скорость» других языков является субъективной характеристикой («при определенных определениях быстрее»).

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++ для симуляции игры.

Parrot — это библиотека для языка Gleam, предоставляющая типобезопасный способ написания SQL-запросов. Она позволяет компилировать запросы на этапе разработки, выявляя ошибки в синтаксисе или типах данных до выполнения кода, что повышает надёжность приложений.

Библиография использует встроенные возможности Gleam для генерации корректного SQL, избегая распространённых проблем вроде опечаток в именах колонок или несоответствия типов. Это особенно полезно в проектах, где важна строгая статическая проверка и минимальное количество runtime-ошибок.

• Участники положительно оценивают sqlc и его порт для Gleam, отмечая преимущества использования чистого SQL с типобезопасностью.
• Обсуждаются ограничения SQL и ORM, в частности проблема композиции и динамических запросов, а также сравнение с другими инструментами (Kysely, PRQL, Django ORM).
• Несколько пользователей спрашивают, что такое Gleam, и получают разъяснения, что это типобезопасный язык для Erlang VM.
• Поднимается вопрос о кроссплатформенности запросов и поддержке разных СУБД, на который автор отвечает, что это зависит от возможностей sqlc.
• Сравниваются системы типов Gleam (статическая) и Elixir (gradual), отмечаются их ключевые различия и предпочтения.

Каталог 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 (строгая типизация).

Первые впечатления о 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 требовала ещё меньше.

Не создавайте мульти-агентов

Фреймворки для LLM-агентов разочаровывают. Ниже — выжимка из нашего опыта и почему популярные идеи работают плохо.

Принципы контекст-инжиниринга

1. Делитесь контекстом целиком
2. Действия несут скрытые решения

Пока в мире LLM мы как в 1993-м с HTML: нет стандарта. Библиотеки вроде OpenAI Swarm и Microsoft Autogen продвигают мульти-агентов, но это, по нашему опыту, ошибка.

Почему мульти-агенты хрупки

Классическая схема:

• разбить задачу на подзадачи,
• запустить под-агентов,
• собрать результат.

Проблема: каждый уровень теряет детали. Пример: «сделай Flappy Bird» → под-агенты делают фон Mario и птицу, не похожую на оригинал. Сводить такие части — головная боль.

Принцип 1
Передавайте не сообщения, а полные трейсы агента.

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

• Пользователи обсуждают, что «агенты» — это просто разные промпты к одному и тому же API, а не отдельные сущности.
• Основная проблема — «размывание» контекста: при ~50 k токенов агенты теряют цель, поэтому многие отказались от сложных мульти-агентных схем в пользу одного агента + умного управления контекстом.
• Предложено строить «компиляторы контекста» вместо ручной курирования и использовать фиксированные pipeline-ы вместо свободно общающихся агентов.
• Некоторые сравнивают подход с супервизорами Erlang, но большинство считает это переизобретением старых идей.
• Общий вывод: пока нет надёжности, мульти-агентные системы неэффективны; начинать стоит с простейших блоков и адаптировать под свою задачу.

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

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

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

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

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

%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 угрожает существующим бизнесам и рабочим местам, а рынок предпочитает «хуже, но дешевле».

Ampere One 192-ядерный сервер, 1 ТБ ОЗУ, цель — запустить максимум виртуальных IoT-устройств на Nerves.

Прошлый раз добрались до 500 экземпляров; теперь с KVM и новым загрузчиком little_loader от Frank Hunleth удалось 5000 одновременных виртуальных ARM64-машин.
little_loader — минимальный ARM64-бутлоадер, читающий переменные u-boot, загружающий ядро Linux и сохраняющий механизмы A/B-обновлений Nerves.

Что изменилось

• KVM/HVF ускоряет старт до 1-2 с и экономит ≈ 500 МБ ОЗУ на гость.
• EL1 вместо EL2: EL2 нужен для вложенной виртуализации, нам не требуется.
• Баг компиляции: release-сборка зависает, debug-версия работает (GCC 15, вероятно, чинит).

Команда запуска (упрощённый пример):

qemu-system-aarch64 \
  -machine virt,accel=kvm \
  -cpu host -smp 1 -m 150M \
  -kernel little_loader.elf \
  -netdev user,id=eth0 \
  -device virtio-net-device,netdev=eth0 \
  -drive if=none,file=disk.img,format=raw,id=vdisk \
  -device virtio-blk-device,drive=vdisk \
  -nographic

Итог: 5000 «эрлангов» на 192 ядрах, 1 ТБ ОЗУ, стартуют за секунды, потребляют по 150 МБ RAM.

• Речь идёт о запуске 5000 узлов BEAM (Erlang-машин), а не процессов — каждая BEAM может держать миллионы лёгких процессов.
• Сервер с 192 Ampere-ядрами позиционируется как «облачный» или «edge» для телекомов; Hetzner предлагает 80-ядерный Ampere за ~200 $/мес.
• Пользователи сомневаются в полезности без тестов под нагрузкой и обсуждают, как масштабировать память и шину при таком числе ядер.
• Всплыли исторические примеры (Azul для Java) и шутки про «ручное ткачество» Erlang-потоков и «фермерский» байт-код.