Hacker News Digest

В статье представлена EPaxos* — упрощенная и исправленная версия протокола Egalitarian Paxos для распределенных систем. Классические протоколы вроде Paxos полагаются на выделенного лидера, что создает единую точку отказа и увеличивает задержку для удаленных клиентов. Egalitarian Paxos предлагает альтернативу без лидера, позволяя репликам совместно упорядочивать команды, сохраняя работоспособность при сбое до f из n=2f+1 процессов. Протокол обеспечивает быстрое выполнение команд за 2 задержки сообщений, если не более e=⌈(f+1)/2⌉ процессов выходят из строя.

Авторы отмечают, что оригинальный Egalitarian Paxos, несмотря на влияние на другие протоколы, страдает от сложности, неоднозначной спецификации и серьезных ошибок. EPaxos* решает эти проблемы с помощью более простого алгоритма восстановления после сбоев, строго доказанного корректности. Протокол также обобщает Egalitarian Paxos на весь спектр пороговых значений отказов f и e, где n ≥ max{2e+f-1, 2f+1}, что авторы доказали оптимальным.

• Обсуждение охватывает вопросы лидерства и консенсуса: Paxos и Raft, EPaxos, EPaxos, Multi-Paxos и Multi-Raft, а также их влияние на производительность и отказоустойчивость.
• Участники обсуждают, что такое "лидер" в контексте распределённых систем, и какие у него обязанности, включая упорядочивание транзакций и обеспечение отказоустойчивости.
• Участники также обсуждают, как различные протоколы консенсуса, включая Paxos и Raft, обрабатывают вопрос лидерства и как они влияют на производительность и отказоустойчивость системы.
• Участники также обсуждают, как различные протоколы консенсуса, включая Paxos и Raft, влияют на производительность и отказоустойчивость системы.
• Участники также обсуждают, как различные протоколы консенсуса, включая Paxos и Raft, влияют на производительность и отказоустойчивость системы.

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

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

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

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

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

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

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