Здравствуйте!
Я - Elixir разработчик.
Это моя профессия.
Так сложилось исторически.

Когда-то я разработал Erlang.
Теперь это язык поддерживающий параллельные легковесные процессы и асинхронность.
Теперь на нём удобно разрабатывать распределённые системы.
Теперь на нём написан RabbitMQ.

Я разработал OTP.
Этот фреймворк я применил про разработке огромного разнообразия высоконадёжного телекоммуникационного оборудования.
OTP стала неотъемлемой частью экосистемы Erlang.

Я разработал BEAM и ERTS.
Вместе они позволяют коду на Erlang эффективно распараллеливаться и надёжно выполняться на разных узлах распределённой системы.

Я обогатил Erlang метапрограммированием и полиморфизмом создав новый язык Elixir, который можно применять везде!

Я создал Phoenix.
Фреймворк с отличной производительность и масштабированием объединяющей в себе всё необходимое для веб разработки.

Да, я - Elixir разработчик!
И я устал извиняться за это...
Я разработчик по праву рождения.
Я проектирую и имплементирую.
Бойтесь!

>>468730

>Удваиваю, мне в целом похуй на мнение этого клоуна. Мне важно только чтобы у поверхностно читающих этот тредик не сложилось неправильное впечатление. Мы-то с тобой знаем детали языка и его использования и поэтому понимаем почему этот клоун не прав, а анон, который просто зайдёт про язычок почитать, деталей не знает и может реально клоуну поверить.

Честно говоря, я плохо понимаю, почему случайному прохожему может по какой-то причине понравиться эрланг. Я помню, как очень много лет назад поинтересовался, что это за эрланг, на котором ejabberd написан, и пришел к решению — это какая-то странная хуйня, и наверное мне не нужная.

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

Даже сейчас, когда я в распределёнке вырос очень сильно, я не совсем уверен в том, что Erlang мне нужен. Встроенный оркестратор — это круто, но проблема разделяемого состояния не решена. Да, можно ответить как разрабы golang: "Don't communicate by sharing memory; instead, share memory by communicating" — но это лишь про другую крайность, а по-хорошему в системе всегда есть потребность в разделяемом состоянии.

И в том числе разрабам дискорда для оптимизиации нетипичного для BEAM способа хранения данных пришлось прибегнуть к помощи внешних инструментов (постгря+редис+кафка), хотя изначально для этого подразумевалось использование Mnesia или какого-то подобного воображаемого инструмента, родного к Erlang (DETS плюс хуй знает что). Тот же Discord категорически не применяет Mnesia, потому что она омерзитольно никак масштабируется.

Теперь внимание вопросы: если работоспособность всей системы зависит от того, не наебнётся ли шардированная постгря, то в чём особенная ценность деревьев супервизии? В чём ценность горячего апгрейда, если 90% ебли заключается в смене схемы постгри? Какая разница в том, какая доля системы сумела восстановиться, если по итогу система в целом неработоспособна, потому что постгря не включена в деревья супервизии?

Как вы понимаете, я уже задавал подобные вопросы нейросетке — она только всплакнула, сказала что-то про "жизнь — страдание, мы все умрём", и ушла в закат.

>>469825

> проблема разделяемого состояния не решена

Это я не совсем понял. В Elixir можно коммуницировать как угодно. Хочешь посылай сообщение. Хочешь, сделай процесс, который будет держать состояние и ему будут мутации посылать (Agent). Хочешь, сделай большой shared KV на ets. Или даже shared граф на ets.

На моём опыте 99% задач (из веба) этими подходами покрываются. Если у тебя что-то очень экзотическое, то пиши NIF на языках где есть shared memory, к счастью в Elixir это не сложно делается, по сравнению с, например, Java.

> если работоспособность всей системы зависит от того, не наебнётся ли шардированная постгря, то в чём особенная ценность деревьев супервизии?

Погоди, а на каком языке можно написать сервер, который дёргает Postgres, чтобы он оставался работоспособным когда Postgres отъебнётся? Или какой язык программирования автоматически данные в постгре мигрирует?

Но в целом, анон, я понимаю откуда у тебя такие вопросы. У тебя просто изначально неправильное понимание того что такое Elixir. Elixir это не про то что у тебя один Elixir заменит и бэкенд, и базу данных, и редис, и кафку и вообще весь софт который есть.

Elixir это про то что у тебя есть очень простая система акторов, очень сильный многозадачный рантайм и очень много ограничений поверх всего этого, чтобы не выстрелить в ногу. И в этом и вся сила. 99% логики бэкенда в нормальном проекте находятся как раз в коде серверов которые эти постгри и кафки дёргают. И Elixir даёт тебе возможность делать эту логику с нормальной асинхронностью, многопоточностью и коммуникацией.

Если конкретнее, и с примерами, тебе на Elixir не нужны редисы, чтобы посылать информацию в соседний поток (как в PHP, например). Тебе и не нужно иметь Senior разраба за 300к/наносек, который будет в твоём мультитредовом говнокоде на мьютексах искать race-condition (как в C++). Тебе не нужен цветной async/await код (как в Python), где у каждой либы есть хуёвый asyncio-аналог, где работает только половина функционала. Ещё у тебя есть supervising и share-nothing из коробки, поэтому, чтобы изолировать ошибки и отключение различных деталей (не типа БД, а типа комнаты чата или подключения к какому-то сервисы, например), ты просто пишешь новый процесс, а не делаешь отдельный микросервис (как в Go).
Как бонус, все ресурсы у тебя инициализруются супервизорами один раз и держутся в живом состоянии (пока это возможно), и тебе не надо писать хаки, чтобы они инициализировались не на каждый запрос (как в Ruby, PHP, Python).

Возвращаясь к твоим вопросам

> Какая разница в том, какая доля системы сумела восстановиться, если по итогу система в целом неработоспособна, потому что постгря не включена в деревья супервизии?

Постгрю никто и не запускает в супервизоре Elixir-а, но вот пулл соединений к базе будет как раз за супервизором. И вот тут как раз хорошо видно отличие Elixir от того же Go.

Если у меня бэк на Go, то отключение бд там, убьёт сервис и он будет лежать пока база не включится обратно, и только потом k8s рестартнет сервис на Go.

А если у меня бэк на Elixir, то у меня отключение бд убьёт пулл. И пулл попадёт в restart loop если ты не настроил так, чтобы падение пулла также за собой выключало application. За это время весь стейт, который был в системе, в ней и останется. Будут падать только те запросы, которые лезут в бд, а те, которые, например, попадают в кэш, не будут падать. Не упадёт также и chat room, который хранится, например не в постгре. Не упадёт также и какой-нибудь стрим, который уже запущен и с бд не взаимодействует. Это будет именно что graceful failure. Зачем? Это тупо сэкономленные деньги, потому что для юзеров половина сайта будет работать, а для половины будут крутиться спиннеры загрузки. В этот момент зритель не закроет твой сайт, чтобы открыть твитч и смотреть стрим там, в этот момент юзер не закроет чат с твоей ллм, чтобы написать в chatgpt, и т.д.

И я эту хуйню не придумал, а это реальная история из моего проекта с аукционами на стримах. У нас во время очень дорогого аука отлетел Elastic насмерть из-за индуса девопса сукка. Люди не могли посмотреть списки товаров на сайте вообще никак, даже название товара. Но при этом тот дорогой аук не прервался, и проект заработал кучу денег на комиссии с этого аука, потому что стримы и чатики никак эластик не трогали.

Так вот, чтобы сделать такой же graceful failure, гоферы либо обарабатывают ошибки в каждом месте где дёргают бд (покажите мне хоть один проект где вообще все ошибки от бд так обработаны), либо (что сильно чаще) пишут микросервисы, чтобы один микросервис обслуживал запросы к бд, другой микросервис обслуживал запросы к чатам, третий стримы крутил. В итоге они выносят эту сложность на уровень инфраструктуры, а это всегда дороже, потому что из-за этого больше разных CI/CD пайплайнов, надо делать апихи друг к другу, обновления микросервисов должны быть всегда независимыми и т.д.

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

>>470450

>Погоди, а на каком языке можно написать сервер, который дёргает Postgres, чтобы он оставался работоспособным когда Postgres отъебнётся? Или какой язык программирования автоматически данные в постгре мигрирует?

При всей адовой дроче на распределённость, уровень развития распределённых вычислений в индустрии очень грустный. То есть, готовые решения есть только для узких ниш, для других ниш решения нужно собирать из кирпичей из клея, а в третьих лепить почти с нуля.
Я застал ещё те времена, когда в постгре вообще не было встроенной потоковой репликации, репликацию делали на логическом уровне, повторяя SQL запросы на нескольких серверах, или же копируя WAL по SSH. Между прочим, Facebook до сих пор использует похожую модель (но давай лучше не будем про Facebook, потому что меня сейчас понесёт).

Такая организация логична, то есть, иерархия железо => машина из железа => сеть из машин. Индустрия уже очень давно делает вещь, которая ебанутая по своей сути: иммитирует работу примитивного железа при помощи машины, а когда не хватает всей машины — при помощи сети из машин. То есть, телега впереди лошади, жесткий диск из кластера машин, оперативная память из баз данных.

Да, это попытка упростить решение, свести сложную задачу к набору известных простых задач, но эти же "простые задачи" создают настолько много проблем, что нужен целый гугл или яндекс для эффективного их решения. Более того, ни гуглу, ни яндексу в хуй не упёрлось создание простого фреймворка организации сложных систем, потому что если завтра каждый васян создаст свою масштабируемую систему без AWS/GCP/Azure/Yandex Cloud, то все эти параши останутся без главного источника заработка. Я неоднократно наблюдал чудовищное переусложнение продуктов в таких корпорациях "потому что мы можем".

Erlang/BEAM уже частично пытались решить подобную задачу — это, как я указал, DETS, который организует локальное хранилище на одном узле, а координацию между узлами нужно писать ручками. Хочешь пиши шарды, хочешь — какую-нибудь иерархию. Другое дело, что какого-то готового фреймворка (по крайней мере публичного) для надёжной организации координации таких хранилищ нет.

>Elixir это не про то что у тебя один Elixir заменит и бэкенд, и базу данных, и редис, и кафку и вообще весь софт который есть.

Да ради бога, используй внешнюю БД. Другое дело, что вот для персистентности лога мне чо использовать в Elixir? Eventstore? Которое опять на той же постгре в качестве бэка работает. Неужели нет в мире других СУБД, кроме постгри?
Обычно микросервисные доходят до маразма и гоняют десяток разношерстных БД, хотя бы ту же постгрю нескольких версий, чтобы когда одна отъебнулась — остальные работают.

>Если у меня бэк на Go, то отключение бд там, убьёт сервис и он будет лежать пока база не включится обратно, и только потом k8s рестартнет сервис на Go....

>Будут падать только те запросы, которые лезут в бд, а те, которые, например, попадают в кэш, не будут падать. Не упадёт также и chat room, который хранится, например не в постгре. Не упадёт также и какой-нибудь стрим, который уже запущен и с бд не взаимодействует.

Не поверишь — ту же самую историю мне рассказывали не так давно, только про микросервисы. "Частичный отказ, незатронутые сервисы продолжают работать, бла-бла-бла...".

>99% логики бэкенда в нормальном проекте находятся как раз в коде серверов которые эти постгри и кафки дёргают.

Из этих 99% (на самом деле порядка 60% в случае того же Discord, остальное выполняется в Kafka, Redis, PostgreSQL, etc) где-то половина выполняет клеевую функцию, то есть, адаптирует одну модель к другой, обрабатывает вебсокеты, доступ к БД, сериализацию. Довольно часто делают это неоправдано сложно, просто чтобы адаптироваться к стороннему сервису, разработанному не нами и не под наши задачи.
Справедливости ради, микросервиснутые нынче вообще ебанулись на отличненько и у них доля клея в коде может доходить до 90-95%, по сути они кроме парсинга и генерации JSON (или имянейм протокола) ничего не делают.

>В итоге они выносят эту сложность на уровень инфраструктуры, а это всегда дороже, потому что из-за этого больше разных CI/CD пайплайнов, надо делать апихи друг к другу, обновления микросервисов должны быть всегда независимыми и т.д.

>Тогда как Elixir наоборот пытается всю такую сложность оставить внутри. Конечно, тебе всё равно нужен какой-то внешний супервизор для постгри, и миграции для базы данных тоже нужны. Но тебе не нужно делать микросервисный зоопарк чтобы ошибка в одной хуйне не выключала другую, совсем не связанную с первой, хуйню. Elixir в этом плане тупо выгоднее и проще.

У гугля все сервисы по сути представляют собой огромный монолит в монорепе, где изменение API делается одним коммитом сразу в кучу сервисов, а само API сделано в виде синхронных вызовов на Stubby/protobuf. То есть, всё связывание сервисов происходит на этапе компиляции и связывается напрямую один сервис с другим, без посредников, без кафок и постгрей. Заметь, что сервисы написаны на разных языках программирования, но по итогу работают как единая система. Если какому-то сервису нужна персистентность — зачастую он единолично взаимодействует с БД, заключая в себе сложность работы со схемой.

Иронично, что уже есть опенсорсные аналоги внутренних инструментов гугла (Borg => Kubernetes, Stubby => gRPC), но почему-то микросервиснутые используют их IRL предельно через жопу, со всякими там Rabbit/Kafka на каждый чих без типизации/версионирования пересылаемых сообщений и без способов отладить проблемы с обработкой этих сообщений, когда продьюсер уже давно съебался, а консюмеры до сих пор не могут понять, откуда эти сообщения высрались и что с ними делать.

>Тебе и не нужно иметь Senior разраба за 300к/наносек, который будет в твоём мультитредовом говнокоде на мьютексах искать race-condition (как в C++).

Мне не нужно его искать — я он и есть, лол.