Hacker News Digest

Gleam v1.19.0 перестал генерировать исходный код Erlang и теперь выводит Erlang абстрактные формы (abstract forms) — внутреннее промежуточное представление, используемое компилятором Erlang. Это позволяет загружать сгенерированный код напрямую в BEAM, минуя этап парсинга и токенизации Erlang-кода. Такой подход ускорил компиляцию: в тесте на 100 модулей по 100 функций время сборки с нуля сократилось с ~400 мс в v1.17.0 до ~150 мс в v1.19.0. Кроме того, метаданные о расположении теперь точно соответствуют исходному коду Gleam, что делает трассировки стека и отчёты о падениях максимально информативными — номера строк указывают точно на место в Gleam-коде, а не на сгенерированный Erlang. Это также открывает путь к полной поддержке отладчиков вроде edb. Изменение улучшило качество компилятора, заменив устаревший модуль генерации кода на современный, соответствующий текущим стандартам проекта. Авторы отмечают, что теперь можно избежать уничижительного термина «транспайлер», поскольку компиляция в бинарный промежуточный формат не уступает по качеству и надёжности генерации читаемого кода. Benchmark основан на langcompilebench José Valima и измеряет чистое время компиляции без кэширования; в реальной разработке благодаря инкрементальной компиляции ускорение будет ещё заметнее. Gleam остаётся типовой и масштабируемой языком для Erlang VM и JavaScript, а это обновление укрепляет его позицию как инструмента для надёжной и быстрой разработки.

Переход Gleam на генерацию Erlang abstract forms ускорил сборку, устранив этап парсинга Erlang-кода. Сообщество активно поддерживает язык за простоту, дружелюбие и зрелость, несмотря на нишевость. Пользователи отмечают, что код на Gleam пишется медленнее, но получается короче, понятнее и проще в поддержке, особенно по сравнению с фронтенд-фреймворками вроде React. Gleam легко осваивается разработчикам, знакомым с Rust, и предлагает быстрый вход в концепции BEAM (акторы, супервизоры), что делает его ценным для обучения. Большинство BEAM-языков (Elixir, LFE и др.) уже используют Erlang abstract forms как целевой формат, что делает переход Gleam логичным и стандартным шагом. Отладка в Erlang-инструментах не препятствует — для интеграции с WhatsApp-отладчиком достаточно передать два флага компилятору Erlang. Giacomo Cavalieri, автор Gleam, получает признание за скромность, доступность и внимание к деталям, включая ручную анимацию презентаций, что усиливает доверие к проекту. Новичкам, не знакомым с Erlang, рекомендуется начинать с Elixir, а не с Gleam, так как он проще для быстрого старта с BEAM и концепциями акторов. Для использования Gleam в продакшене без подходящего проекта советуют начать с небольших инструментов или веб-приложений, чтобы оценить его преимущества на практике. Есть споры о термине «transpiler»: одни считают его нейтральным и корректным (Gleam транспилирует в IR), другие — неоднозначным или оскорбительным, подразумевающим низкое качество. Также обсуждается визуальный стиль Gleam: один участник сравнил его с «игрушками для девочек», что вызвало возражения — другие считают это субъективным суждением. Несмотря на рост LLM-инструментов, Gleam сохраняет ценность как язык, созданный человеком с фокусом на простоту и надежность, что отличает его от автоматически генерируемого кода.

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

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

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

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