
Предыдущий: >> 2954172
Сегодня хочу рассказать тебе о прекрасном функциональном языке для написания неубиваемых распределённых систем, а более конкретно вебни на бэке, больших soft-realtime систем, IoT говен и оперденей. Называется он Elixir, а работает он на виртуальной машине real human BEAM, на которой ещё работает язык Erlang.
Немного истории
Эликсир это современный язык, построенный поверх языка Erlang с блекджеком и лисповыми макросами. У этих языков полный интероп в обе стороны, но при этом эликсир лишает вас этого удовольствия написания. Сам язык Erlang появился в компании Ericsson как язык для написания максимально отказоустойчивых телекоммуникационных систем. Именно из желания создать среду для написания максимально отказоустойчивых систем появились все основные фичи.
Основные фичи
⚹ Ахуенно приспособлен к разработке параллельных и конкуррентных программ. Эликсир способен запускать мильоны процессов-акторов, работающих асинхронно, с различными приоритетами и всем таким. Эти процессы не делят память и общаются через пересылку сообщений.
⚹ Ахуенно приспособлен к разработке распределённых систем. Все основные проблемы написания распределённых систем вроде сихнронизации монотонных часов, общения между машинами, поиска машин, heartbeat-ы, группы процессов, gossip-ы уже включены в язык.
Любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang. (с)
⚹ Ахуенно приспособлен к разработке отказоустойчивых систем. Что делают кубы, когда падает сервис? Они перезапускают его. Эрланг делает то же самое, только не с сервисами, а с процессами, и это значит что неожиданное исключение в одной части функционала никак вообще никак не заденет другой функционал. Гоферы пытаются достичь того же с помощью микросервисов, а в Elixir такой функционал изкоробки.
⚹ Ахуенный тулинг. В отличие от эрланга с его хэдерами, makefile-ами и прочими пыльными приколами, эликсир за секунды позволяет создать проект, скомпилировать его, сконфигурировать его, собрать артефакт, скачать зависимости и всё такое в стандартах всех современных языков. Серьёзно, местный билдтул (mix) гораздо лучше чем забугорские cargo, npm, go и gem.
Нахуя
Ты хочешь нормально спать по ночам? Ты хочешь отказаться от ночных дежурств? Ты хочешь сэкономить на этих богомерзких девопсах и прочих сисянах? Ты устал дебажить очередной дата-рейс ебучих горутин?
Я хочу спать по ночам. Как вкатиться?
Чтобы успешно найти работу на эликсире, нужно уже иметь некоторый опыт разработки за деньги и понимание того какое же говно это ваше ойти. Желательно от одного года в вебе. Самый быстрый способ обучения это в то же время и самый эффективный способ, поэтому синтаксис и стандартная либа постигается вот тут
https://elixirschool.com/ru
Более подробное описание внутренностей, хороших практик и хитростей стандартной либы описывается вот тут. Тут будет эрланг, но это не должно быть проблемой
https://learnyousomeerlang.com/
Конкретно вебня на эликсире
платно: https://www.amazon.com/Programming-Phoenix-1-4-Productive-Reliable/dp/1680502263
бесплатно: https://hexdocs.pm/phoenix
Тому, кто ценит своё время, я советую начать писать какой-нибудь проектик параллельно с чтением книжек. Чтобы стать джуном на эликсире опытному бэкендеру нужно не больше месяца.
Рыночек
Средняя температура по больнице зарплата у эликсирщика традиционно больше чем у любого друогого языка как минимум в два раза, поэтому поменять голанг или питон на эликсир будет выгодно. Вакансии на рынке РФ существуют, искать можно на hhрю или в чатиках в телеге t.me/proelixir. Забугорных вакансий значительно больше и они охотно нанимают разработчиков с опытом. Самое важное качество при найме это не знание самого языка, а софт-скиллы и общее понимание веб-разработки как таковой, так что придётся социализироваться.
Вопросы?
Я её написал, я её и сохранил. Правда я не осилил ссылку на предыдущий тренд, но в архиваче, так что похуй

Я - Elixir разработчик.
Это моя профессия.
Так сложилось исторически.
Когда-то я разработал Erlang.
Теперь это язык поддерживающий параллельные легковесные процессы и асинхронность.
Теперь на нём удобно разрабатывать распределённые системы.
Теперь на нём написан RabbitMQ.
Я разработал OTP.
Этот фреймворк я применил про разработке огромного разнообразия высоконадёжного телекоммуникационного оборудования.
OTP стала неотъемлемой частью экосистемы Erlang.
Я разработал BEAM и ERTS.
Вместе они позволяют коду на Erlang эффективно распараллеливаться и надёжно выполняться на разных узлах распределённой системы.
Я обогатил Erlang метапрограммированием и полиморфизмом создав новый язык Elixir, который можно применять везде!
Я создал Phoenix.
Фреймворк с отличной производительность и масштабированием объединяющей в себе всё необходимое для веб разработки.
Да, я - Elixir разработчик!
И я устал извиняться за это...
Я разработчик по праву рождения.
Я проектирую и имплементирую.
Бойтесь!
Я - Elixir разработчик.
Это моя профессия.
Так сложилось исторически.
Когда-то я разработал Erlang.
Теперь это язык поддерживающий параллельные легковесные процессы и асинхронность.
Теперь на нём удобно разрабатывать распределённые системы.
Теперь на нём написан RabbitMQ.
Я разработал OTP.
Этот фреймворк я применил про разработке огромного разнообразия высоконадёжного телекоммуникационного оборудования.
OTP стала неотъемлемой частью экосистемы Erlang.
Я разработал BEAM и ERTS.
Вместе они позволяют коду на Erlang эффективно распараллеливаться и надёжно выполняться на разных узлах распределённой системы.
Я обогатил Erlang метапрограммированием и полиморфизмом создав новый язык Elixir, который можно применять везде!
Я создал Phoenix.
Фреймворк с отличной производительность и масштабированием объединяющей в себе всё необходимое для веб разработки.
Да, я - Elixir разработчик!
И я устал извиняться за это...
Я разработчик по праву рождения.
Я проектирую и имплементирую.
Бойтесь!
>Теперь на нём написан RabbitMQ
... единственное ПО на эрланге, используемое за пределами эрланг мира.
Да, реально. За доллары сильно проще чем не за доллары. На ~5к можно рассчитывать если миддл. Если сеньор, то как добазаришься, тут нет верхней планки, средняя это 7-10к где-то.
Раст не сложный язык. Сложный язык это С++ (сложность не в синтаксисе а в понимании всех нюансов использования).
о нихуя буквально год назад начали типы добавлять в язык. ну все, походу я к вам в лодку запрыгиваю
раст не сложный а душный, мне комьюнити чето не нравится растовское и скандалы какие то вокруг актикса итд
>мне комьюнити чето не нравится растовское
Двачую. От них ощущение что раст - это вообще самое сложное что они осилили в этой их ит-жизни. И теперь они носятся с ним как с писаной торбой
Это явно хреновый признак. Такое же за яваскриптунами ещё замечал, лет 15 назад
Патаму что это одни и те же люди
Ещё чатик в телеге. Ещё сайтик elixirjobs. Ещё elixirforum. Иногда особо одарённые ищут в твитторе
На нём только для сетей чё-то пишут? Или бэкенд тоже?
Вебмакака как всегда неспособна рассматривать технологии иначе чем через призму пригодности для написания крудов.
Из того что я видел в вакансиях это бэкэнды, вебсайты (любые, от ecommerce до стриминга видео и приложений), телеком, сервисы, брокеры, ML, нейросети, IoT, алготрейдинг, боты в телеге
Ну ты примерно понял
Ясно. Кароч гиковский язык для нитакусей.
> Вопросы?
Да какие тут вопросы, ещё более мёртвая вещь чем Ruby и Rails
И явно не для вкатунов, не представляю как на нём работу искать, очень редко на hh может мелькнуть вакансия
> И явно не для вкатунов
И почему это плохо?
> не представляю как на нём работу искать, очень редко на hh может мелькнуть вакансия
Так и не ищи на hh. Elixir это не про работу в РФ. Выше скинули сайты, где надо искать работу, и там дохуя вариантов на любой вкус и цвет

>Вакансии на рынке РФ существуют, искать можно на hhрю или в чатиках в телеге t.me/proelixir.
Десяток вакансий за последний год. Да на дельфи работы больше.
Вау, прикольный язык так-то оказывается. Чисто пофаниться можно смены в 1с вечерком, идеальный варик.
Не все постят с хэштегом, смотри в закрепе в сообщениях. Ну и да, разрабов-то тоже мало, поэтому норм что вакансий мало
Хочу сделать табличку, в которую клиенты компании будут ходить и смотреть данные из нашей БД. Чтобы была сортировка, фильтрация по столбцам, поиск, выбор колонок и т.д.
С одной стороны хочется, чтобы писать кода надо было минимум, потому что люди, которые будут это в будущем поддерживать, скорее всего, далеки от современной веб-разработки. С другой хочется, чтобы всё было прозрачно, а не спрятано за кучей слоёв фреймворка, чтобы мне одному проще было в этом разобраться.
Собственно, я придумал только два варианта:
1) Elixir + Phoenix LiveView. Не уверен, насколько мало надо писать в итоге кода, но выглядит как то, что мне нужно. Проблема в том, что кроме меня в эликсире вряд ли кто-то захочет разбираться.
2) Go. Просто в тупую получать запрос и генерить HTML в ответ. Максимально прозрачно, но много кода. Зато если что, разрабов будет проще найти.
Есть ещё какие-то варианты?
Это дохлый тред, если ты не понял.
> Зато если что, разрабов будет проще найти.
Я бы на твоём месте отталкивался от этого. Эликсир, кмк, язык отличный, но слишком нишевый, чтобы с ним можно было уверенно экспериментировать в профессиональной среде, потому как сотрудников ты действительно не найдёшь.
Забеги на elixirforum.com, там достаточно лояльное сообщество, спроси про свои беды. Тебя направят, помогут определиться.
> Это дохлый тред, если ты не понял.
Дохлая это твоя мать
>>406487
>Проблема в том, что кроме меня в эликсире вряд ли кто-то захочет разбираться.
Эликсир проще чем руби и питон, там разбираться не нужно. Эликсир с нуля учится за две недели. В год можно изучить до 26 эликсиров.
> Хочу сделать табличку, в которую клиенты компании будут ходить и смотреть данные из нашей БД. Чтобы была сортировка, фильтрация по столбцам, поиск, выбор колонок и т.д.
https://hexdocs.pm/kaffy/readme.html
https://hexdocs.pm/torch/readme.html
реббит с scheduled tasks плагином не варик так как оно сносно работает только с датами в скором будущем + потенциально проебывать некоторые запуски не оч хорошо поэтому нужна запись в базу
Если оформлять вкат в эликсир здорового человека - по-хорошему нужно освоить эрланг для начала? 5 лет назад внезапно столкнулся на работе с эрлангом, рефакторил старый сервер, было сложно пердолиться, но парадигма языка запала в душу с тех пор. С элексиром я так понимаю карьерные перспективы становятся кратно выше.
> Подходит ли этот язык для таких "долго работающих" задач и удобное ли взаимодействие с этими процессами, отслеживание упало/не упало, обработкак ошибок, запросы по сети делать на сайты, доступ к БД, файлой системе?
Да, подходит больше чем Elixir, с ним не нужны хаки типа multiprocessing, не нужнен ебучий async/await, просто пишешь как обычно пишут на Elixir и всё асинхронность и многопоточность будет из коробки
>>441520
> Хочу сделать запуск процедур по расписанию точково (как scheduled сообщения в телеге) - как это сделать в эликсирчике с фениксом?
Лучше всего через job queue какой-нибудь. Или можно на коленке: класть в базу что нужно в такое-то время отправить сообщение. и вешать Process.send_after. На старте и, например, раз в день, читать из базы и обновлять таймеры
>>441632
Отдельно учить Erlang не нужно, он сам учится в процессе освоения Elixir, различия будут только в не очень важных деталях типа там синтаксиса и немного других модулей. Кароче, учи сразу Elixir и не парься. Работы на Elixir больше, это факт, особенно если ты джун/миддл. На Erlang работа есть только для очень опытных, и чаще всего в легаси проектах
> Да, подходит больше чем Elixir
Больше чем Python, я имел в виду.
В питоне нет многопоточности и асинхронности нормальной. В Elixir это всё сильно проще и удобнее
Я попросил нейросеть написать сервис на ерланге и то же самое на эликсире. Если в эрланге есть математическая красота, то эликсир какой-то всратый, будто эрланг измазали джаваскриптом. Впрочем, вкатиться импосибл в оба, на рынке полторы вакансии с требованиями 5+ лет опыта.
>Чтобы стать джуном на эликсире
Все равно, что пытаться найти работу на Erlang, Haskell или OCaml. Смысл лезть в полумертвые языки, где тулинг, библиотеки и фреймворки остановились в развитии на уровне начала 00-х годов? Тут даже на популярном стеке проблематично найти работу, что уж говорить о такой экзотике
>даже на популярном стеке
Как раз во всякой дохляди должно быть проще, потому что там не то что волков и упругих зумеров, там вообще желающих с этим возиться даже предпенсионного возраста хуй найдёшь. Поэтому на такое обычно берут всех, кто не совсем тупой, имеет хоть сколько-то серьёзный опыт (пусть даже сраных петпроектов) и замотивирован развиваться дальше.
>там вообще желающих с этим возиться даже предпенсионного возраста хуй найдёшь
Это либо переписывание интернет магазинов с руби он реилс на эликсир и феникс, либо, если мы говорим про эрланг, то в 99% случаев это телеком где эрланг вообще сбоку и нужен как клей для модулей на сишке. Вакансий так же полторы штуки и залетные нахуй не нужны. Окамл хз где используют кроме как в джейн стрит где от него потихоньку отказываются. Скала сдохла. Хаскелл тупо академическая залупа. Была вакансия в тиньке даже, но там искали яйцеголового любителя фп, чтобы он какой-то рулер писал для кредитования. Еще в барклейс искали хаскеллиста. Это настолько нишевая и точечная хуйня, что желающих попасть будет побольше чем на какой-нибудь гоулэнг, т.к. у тебя рили вакансий - раз два и обчелся
Асинхронности нормальной нет. async/await уже весь мир, включая самих питонистов, признал как полный кал. Посмотрите на Elixir, Go, Java, Rust, там везде нормальные гринтреды/csp.
Многопоточности нет. multiprocessing это хак, который с async/await никак не интегрирован. А многопоточные wsgi серверы это позор уровня PHP. Например, если у меня один процесс будет набит работой, а другой будет пустой, то рантайм автоматически их не сбалансирует и не распараллелит, а это надо будет делать разработчику
> на рынке полторы вакансии
Это в РФ, смотри Европу и США, там охотно нанимают на релокейт из любых концов мира. На моём проекте больше половины разрабов это СНГ и Индия/Китай (примерно поровну каждых). Спрос на разрабов есть
> тулинг, библиотеки и фреймворки остановились в развитии на уровне начала 00-х годов
Ну тут ты не прав. У Elixir пиздатейший тулинг, тот же mix, например, сильно удобнее чем даже cargo. А фреймворки, посмотри на Phoenix, например. Они первыми сделали LiveView, там очень сильный PubSub, вот сейчас завозят PhoenixSync, который типа eventually consistent database sync сразу на клиенты.
Библиотеки тоже на любой вкус. Пиши что тебе нужно, я подскажу либу
> Это либо переписывание интернет магазинов с руби он реилс на эликсир и феникс
Нихуя, я думаю на Elixir e-commerce вообще не очень популярен. Большая часть проектов на Elixir это всякие интерактивные вебсайты, стриминги, чатики, какие-нибудь бэкенды. Ещё Elixir в IoT и ML присутствует
> если мы говорим про эрланг, то в 99% случаев это телеком где эрланг вообще сбоку и нужен как клей для модулей на сишке
Это было правдой лет 20 назад, когда всё писали на C/C++ и мультитрединг там был очень душный, поэтому параллелили через Erlang. Сейчас на Erlang есть и телеком, и вон много всякой IO-bound хуйни пишут типа EMQX, бд типа CouchDB, тот же RabbitMQ. Но сейчас уже Erlang и правда больше легаси и вытесняется Elixir-ом
Gleam норм тема. Пока что он слишком сырой для прода, там не хватает экосистемы и всякие моменты внутри языка пока ещё не готовы (вроде статической типизации акторов).
Поэтому это риск, ведь не факт что Gleam успеет обрасти экосистемой раньше чем у Elixir появится статическая типизация.
>PubSub
Не нужен. Все системы на шине событий превращаются в говно.
>eventually consistent database sync
Оу май гад соу мач базворд ориентед девелопмент!
Вангую все закончится еще одним KV хранилищем, снова.
>Ну тут ты не прав. У Elixir пиздатейший тулинг
Хотя бы IDE нормальную завезли уровня IntelliJ IDEA?
>Библиотеки тоже на любой вкус
Кто из крупных игроков вкладывается в развитие тулинга и библиотек/фреймворков в эликсире? Именно крупные компании, которые разрабатывают и поддерживают эти решения, а не ноунейм пердольки, которые выпукивают свои поделки на гитхаб
Последний раз, когда я тыкал Эрланг, там даже нормальной поддержки со стороны IDE не было. Фанатики убеждали меня, что IDE это фу-фу и норм писать в обычном текстовом редакторе, временами переключаясь в терминал и пытаться скомпилировать код, чтобы получить сообщения об ошибке и затем идти обратно в редактор, чтобы их пофиксать. Про интеграцию со всякими дебагерами, запуском приложения и т.д. и т.п. я не говорю - этого нет
На эрланге все саксесс сторис которые я видел это демонвейр с их сервером для калловдути и прочие поделки из мира телекома где эрланг вообще сбоку и нужен тупо как клей. С приходом гоулэнга и клауд нейтив в виде контейнеров и кубера эрланг нахуй выкинули.
А эликсир это как раз попытка влезть на поляну руби и рор с его интернет-магазинами и сайтами визитками
> Хотя бы IDE нормальную завезли уровня IntelliJ IDEA?
Ты из каменного века пришёл? В твоём мире колесо изобрели или пока нет? Какие нахуй IntelliJ IDEA, ты ебанулся? Весь мир пишет весь код в VSCode или Cursor, которые тупо пользуются language server-ом (для эликсира такой есть)
> Кто из крупных игроков вкладывается в развитие тулинга и библиотек/фреймворков в эликсире? Именно крупные компании, которые разрабатывают и поддерживают эти решения, а не ноунейм пердольки, которые выпукивают свои поделки на гитхаб
Нихуя не понял как это с качеством связано. Я смотрю на Java и вижу что там много корпоративного кала, который меняется от версии к версии и нихуя стабильного там нет. И я смотрю на Elixir, где есть куча качественного софта, большинство из которого крутится в реальных продах и ежедневно улучшается этими компаниями
> А эликсир это как раз попытка влезть на поляну руби и рор с его интернет-магазинами и сайтами визитками
Не знаю, может из того тугого очка, откуда ты на мир смотришь, так и кажется, но у меня дохуя лет опыта в экосистеме и это нихуя не так. Хочешь саксесс стори на Elixir? Дискорд. Дальше продолжать или может хотя бы погуглишь прежде чем здесь писать своё ахуенно полезное мнение?
> Не нужен. Все системы на шине событий превращаются в говно.
Это не про шину событий, а про PubSub, типа как MQTT, только без стороннего сервера, а прям внутри системы. Очень удобно, так как тупо оптимизирует весь поллинг в местах, где нужен синк всяких вещей которые меняют разные клиенты (типа там чатов или стримов или чего-то такого)
> Вангую все закончится еще одним KV хранилищем, снова.
Мимо родной, почитай хотя бы доку. Суть PhoenixSync такая: ты можешь считай подписаться на SQL запрос в постгрю. Ты типа этот запрос шлёшь в базу и тебе возвращается бесконечный стрим, внутри которого лежат все изменения по этому запросу. Пока что оно работает только на очень тупых запросах и плоских таблицах, но в целом это считай автоматическая инвалидация кэшей. Где ты такое ещё видел?
>Весь мир пишет весь код в VSCode или Cursor, которые тупо пользуются language server-ом (для эликсира такой есть)
Очевидно, ты не понимаешь, что такое IDE и поддержка языка программирования в нем. Твой вскод обычный текстовый редактор. lsp вообще не решает проблем про которые я говорил. Автокомплит, поиск по коду и прочие интеграции в вскоде не реализованы
> Очень удобно,
Представил картинку с ртом в говне.
Удобно это сигналы, потому что они локальны и конкретны. Можно строить иерархии сигналов, можно делать условия передачи сигнала, можно строить сетевые экраны и транспорты которые работают с сигналами из какой-то области видимости. Можно делать что угодно, блядь. И это наверняка в ерланге уже давно реализовано. А пабсап. Ну. Что-то из мира ООП-кала с протёкшей абстракцией, да?
Лучше бы они придумали что-то чтобы эликсир в си компилировался. Вот это полезно.
>Но сейчас уже Erlang и правда больше легаси и вытесняется Elixir-ом
Тут проблема даже не в том, что он легаси, сколько в том, что и Erlang, и Elixir очень нишевый и на них очень мало проектов создаётся. Чисто в сравнениюю с проектами на том же Python, которых в тысячу раз больше.
>>466908
>Иными словами, дергаем запрос по кд. Зумеры изобрели поллинг.
Дык это не полинг, это пушинг.
С другой стороны, я согласен, что шина событий и централизированные KV-зранилища — это ебаный рак. Каждый раз, когда кто-то делает распределённую систему, выпрыгивает тимлид-архитектор и орёт "нужно централизованное ACID-complaint хранилище, по best practice". Какого хуя вообще в Elixir делает постгря? Вот что хотелось бы спросить.
По сути писание системы на Elixir+Phoenix+PostgreSQL делает её заменой для Ruby+RoR+PostgreSQL — "заменой" в том плане, что Ellxir намного быстрее и масштабируемее. По производительности и модели выполнения оно ближе к Go+Gin+PostgreSQL при том допущении, что у вас один хуй централизированная параша, а отдельные распределённые сервисы вы будете оркестрировать каким-нибудь кубернетом.
> Автокомплит, поиск по коду
Реализованы. Прочие интеграции это какие? Дебаггер есть в elixir-ls. Интеграция с iex есть в VSCode через плагин. Ты по сути-то напиши, что тебе нужно
Я не понимаю тебя, долбоёб, ты что в этом треде забыл? Есть сигналы, есть телеметрия, есть эвенты, есть пабсаб, есть хуйня на любой вкус и цвет.
Твой аргумент-то в чём? В том что тебе пабсаб не нравится? Так и не пользуйся, дегенерат, возьми любую другую хуйню. Мне лично на пабсаб тотально похуй, у меня нет никаких чувств к нему, я подключаю его когда он решает мне вполне конкретные проблемы. Я тебе, ебанат, не предлагаю ебаным пабсабом решать каждую проблему распределённого мира.
Пошёл нахуй из треда обратно на питоне писать
Мой аргумент в том, что этот кал идёт по пути развития пхп - прямо нахуй в бездну. Вместо допиливания реально важного - быстродействия, занимаются какой-то хуйней.
Ты меня заебал, я тебя в другой тред послал, потому что ты пишешь хуйню про которую вообще нихуя не знаешь. Реально, твоё мнение будет очень ценным в тредике про питон или по какому там ещё игрушечному языку ты осилил "введение для чайников" прочитать. Сюда свои высеры не пиши.
Ну вот просто посмотрим на хуйню, которую ты написал и оценим насколько ты прав чисто чтобы ты сам понял насколько твои высеры тут никому нахуй не нужны.
> Вместо допиливания реально важного - быстродействия, занимаются какой-то хуйней.
Во-первых, PubSub-ом для Phoenix и разработкой рантайма занимаются совершенно разные люди. Это вещи разного уровня, внутри там разные технологии, совершенно разная экспертиза требуется.
Во-вторых, про быстродействие, в релизах OTP регулярно происходят оптимизации. С того как в OTP 24 появился JIT, каждую версию они его допиливают, вводят статическую типизацию на уровне Core Erlang (один из IR-ов), чтобы JIT генерировал как можно более быстрый нативный код.
В-третьих, твои набросы на PubSub это просто постная хуйня. Если ты не знаешь как пользоваться PubSub-ом и в каких задачах его применяют, то ты автоматически идёшь нахуй. Конечно, ебать, если ты на PubSub писал движок для сетевой видеоигры, ты насосал хуёв c PubSub-ом, но ты их насосал не потому что PubSub хуйня (он как раз не хуйня), а потому что ты долбоёб конченный применил технологию там, где она нахуй не нужна и для чего она не подходит. Если у тебя между ушей сейчас какие-нибудь две клетки мозга замкнутся, я думаю ты поймёшь что я имею в виду, но, к сожалению, шансы очень нахуй не велики
> Ты меня заебал, я тебя в другой тред послал,
Ещё мочератору поплачь что в твоём треде срут и постят неприятное, хех
> Во-первых, PubSub-ом для Phoenix и разработкой рантайма занимаются совершенно разные люди.
Ага, так же как дистры хрюникса пишут разные люди которые не могут хоть как-то собраться и найти компромисы. Итог очевиден.
> С того как в OTP 24 появился JIT,
> вводят статическую типизацию на уровне Core Erlang (один из IR-ов),
А ясно, вопросов больше не имею. Дебичи думают что они такие же гении как в гугле с их V8. Типы нужно на уровне языка внедрять, какими угодно способами, чтобы не пилить безумное говнище на жите которое совершенно точно работать не будет.
> В-третьих, твои набросы на PubSub это просто постная хуйня. Если ты не знаешь как пользоваться PubSub-ом и в каких задачах его применяют, то ты автоматически идёшь нахуй.
Пабсаб применяют говноеды которым норм протёкшие абстракции хавать. Больше тут нечего сказать.
> Если у тебя между ушей сейчас какие-нибудь две клетки мозга замкнутся, я думаю ты поймёшь что я имею в виду, но, к сожалению, шансы очень нахуй не велики
Уверен, ты уже замечал какие-то неприятные моменты в пабсабе, именно по этому у тебя так разорвалась твоя говноедская жопа. Ты знаешь что я прав, а ты поел говна.
Начнём с того что ты писал что надо сделать компилятор в C. Эта хуйня уже была для Erlang (до R1 версии, если я не ошибаюсь) и работало ультрахуёво из-за того что разные компиляторы и под разные системы компилируют совсем по-разному и из-за того что это было тупо медленно, так как было две компиляции вместо одной. И ещё была такая система как HiPE, которая AOT компилировала в натив через LLVM, и это тоже был кал. Так что тут ты проебался и нихуя знаешь
Далее, ты написал что типы не внедряют. Но под Elixir и Erlang есть статическая типизация в виде Dialyzer (она unsound, чисто чтобы банальные ошибки ловить) и есть ещё проект который в процессе с полноценной статической типизацией для Elixir. А, ну и есть Gleam, который уже со статической типизацией. Оп-па, ты и тут проебался и нихуя не знаешь.
Дальше про PubSub ты какую-то хуйню пишешь. На PubSub пишут не только в Elixir, есть ещё MQTT, есть всякие платные аналогичные сервисы от cloud-провайдеров типа AWS SNS и аналогов, и есть ещё дохуя других PubSub решений. Люди на MQTT-брокерах делают заводы на IoT платках, которые заменяют успешно заменяют заводы на которых работают как раз такие долбоёбы вроде тебя. И пока ты тут пиздишь что это PubSub это ненужный кал, люди используют PubSub решения и гребут бабки лопатой. И даже здесь ты проебался.
В итоге, в каждой хуйне, которую ты тут высирал, ты был фактически не прав. Не то что бы это были какие-то открытые вопросы, и у нас было разное мнение, а это были тупо факты, которых ты не знал, и тупо кукарекал в моём тредике. Поэтому я и прошу тебя съебаться нахуй отсюда и не ебать тут адекватным людям мозги своими высерами
Заорал нахуй с завода на пабсабе! Ебало инженера представили который ходит по цехам и пытается понять интерфейсы каждого устройства, потому что документация немного не в порядке.
Пиздец ты фантазёр-дегенерат, братишка.
Алсо, ты не понимаешь что пабсаб вообще не предназначен для заводов, потому что нужна надёжная доставка сообщений и логирования, а это ломает всю парадигму пабсаба - низкую связанность. Это классически архитектурный проёб от долбоёба на архитекторе. Видимо ты даже не писал никогда на пабсабе, если этого не понимаешь.
Не буду утруждать тебя размышлениями, а то ещё умнее станешь.
Пиздец как мимо ты пишешь, родной. Почитай про MQTT и основные места его применения. Доставка бывает достоверной, а бывает надо собрать данные со 100500 различных датчиков, и вот тут и используют MQTT. Опять же, у тебя очко шире чем кругозор. Ты меня просто заебал своей поверхностной хуйнёй
>MQTT
>Доставка бывает достоверной
Ладно, так и быть, раскрою немного секретов необразованцу-фантазёру. Backpressure. Думай теперь.
Что backpressure? Ты понимаешь что такое датчик? Это микромаленькая одноплатная хуйня на 50кб памяти, которая может послать сообщение по UDP, но не может сохранить в памяти больше чем 2 сообщения. Какой нахуй backpressure в IoT
Поэтому и используют MQTT: если сабскрайбер не хочет получать сообщение, он его просто скипает, потому что других вариантов у него особо и нет. И, если что, у MQTT есть 3 уровня разных гарантий доставки (от клиента брокеру).
Опять же, ты проёбываешься буквально в каждой хуйне, которую пишешь.

>Хочешь саксесс стори на Elixir? Дискорд.
В голосину с этой саксес стори
https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users
Discord переписывают два небольших алгоритма на Rust чисто для работы с мутабельной shared-memory и из-за этого все остальные 99.9% кода перестают быть Elixir-ом?
Ты ахуеешь, но рантайм языка и многие встроенные модули (типа crypto) написаны на C. Как и, например, Nx это один большой NIF. Получается нет ни одной программы чисто на Elixir?
По факту история повторяется с эрлангом. Элексир используют как клей для модулей на других языках
Что значит клей? Elixir более высокоуровневый язык чем C или Rust, конечно. Я бы даже сказал что он более высокоуровневый чем Java, C# и даже Python. Но даже эти же C#, Java, Python очень часто используют нативный код в том или ином виде (как минимум openssl). Но это не значит что эти языки это клей для C, потому что большая часть кода и логики там всё равно на высокоуровневом языке.
В случае с дискордом, там Rust-а очень мало. Если Elixir это клей для Rust, то хули у них клея в сотни раз больше чем Rust-а. По твоей логике можно сказать что C в юзерспейсе это клей для системных вызовов, а операционная система это клей для драйверов, а драйвера это клей для ассемблера. Кароче, нихуя нормального по твоей логике не получается
>Discord переписывают два небольших алгоритма на Rust чисто для работы с мутабельной shared-memory и из-за этого все остальные 99.9% кода перестают быть Elixir-ом?
Там переписали 2 ключевых для перформанса участка. Потому что вся эта концепция с отсутствием разделяемой памяти, работает на узком класс задач типа телекома. А в большинстве обычных задач разделяемая память нужна. Тебе уже правильно сказали, в этой задаче эликсир просто клей. При желании они могли бы питон использовать для этого.
Родной, ты вообще статью прочитал? Твои высеры никак к аргументу что 99.9% бэка у них на Elixir не относятся и ему не противоречат.
Переписали два алгоритма на раст и ускорили свою систему. И что дальше-то? О чём это говорит? О том что Rust компилируется в zero-runtime натив, а у Elixir есть рантайм? Нихуя себе, вот это ты мне глаза открыл ебать.
А дальше-то что? Какой вывод? Что Elixir клей? Ну, ебать, если систему где весь код на Elixir кроме 300 строк на Rust, ты классифицируешь как "Rust — ядро, а Elixir — клей", то о чём с тобой вообще говорить-то нахуй. Если так, то я вообще удивлён как ты на клавиатуре тогда по кнопочкам попадаешь
>Родной, ты вообще статью прочитал? Твои высеры никак к аргументу что 99.9% бэка у них на Elixir не относятся и ему не противоречат.
Мудило! 99% это твоя больная фантазия, они пишут про
>One big project
У них вообще зоопарк языков https://github.com/orgs/discord/repositories?type=all от С++ до Скалы.
>Переписали два алгоритма на раст и ускорили свою систему. И что дальше-то? О чём это говорит? О том что Rust компилируется в zero-runtime натив, а у Elixir есть рантайм? Нихуя себе, вот это ты мне глаза открыл ебать.
Дебил, ты бы прочел о чем там вообще пишут:
>how we update the Member List
Там личерали речь идёт о приложении которое обслуживает список пользователей в канале. Понятно, что структура которая хранит и управляет этим списком, это главное, что влияет на перформанс приложения, о чем собственно статья и говорит.
>А дальше-то что? Какой вывод?
Эликсир нишевый продукт, который мало кому уперсы.
>о чём с тобой вообще говорить-то нахуй. Если так, то я вообще удивлён как ты на клавиатуре тогда по кнопочкам попадаешь
Дебил удивляется, что с его тупым мнением не согласны. Только на двачах, без регистрации и СМС.
>Там переписали 2 ключевых для перформанса участка. Потому что вся эта концепция с отсутствием разделяемой памяти, работает на узком класс задач типа телекома. А в большинстве обычных задач разделяемая память нужна. Тебе уже правильно сказали, в этой задаче эликсир просто клей. При желании они могли бы питон использовать для этого.
После такого градуса хуйни троль обычно отправляет в игнор. То есть тут настолько лютейшая хуета и некомпетентность в каждом предложении, что я даже не ебу, о чем разговор продолжается.
Ладно если человек мало понимает в предмете и старается понять, но этот ведь даже не старается.
Вы просто засираете тред своим спором.
> Вы просто засираете тред своим спором.
Удваиваю, мне в целом похуй на мнение этого клоуна. Мне важно только чтобы у поверхностно читающих этот тредик не сложилось неправильное впечатление. Мы-то с тобой знаем детали языка и его использования и поэтому понимаем почему этот клоун не прав, а анон, который просто зайдёт про язычок почитать, деталей не знает и может реально клоуну поверить.
>>468698
> зоопарк языков
> 99% это твоя больная фантазия, они пишут про
Сразу понятно что ты дальше своей жирной залупы нихуя не видишь. Большинство репок там это форки либ для фронтендов, для клиентских приложений.
> приложении которое обслуживает список пользователей в канале
Не приложении, а структуре: OrderedSet, который списочек юзеров просто, и всё. Нихуя больше. Чисто структурка которая показывает всех юзеров в гильдии. Основной функционал приложения (войс, чаты) написаны на Elixir (не считая кодеков, которые как либы на C++)
> Эликсир нишевый продукт, который мало кому уперсы.
Так тебя никто не заставляет им пользоваться. Не обижайся, но всем здесь на тебя абсолютно похуй. Да-да. Можешь пожаловаться маме, а потом рассказать ей ещё пару интересных фактов про языки программирования, которые ты сам придумал. Но реальность от этого не изменится. А состоит она в том, что Discord, Remote, WhatNot и кучи других компаний написали свои бэки на Elixir и теперь гребут ахуенные бабки, пока ты здесь с пеной у рта доказываешь что на Elixir нихуя нельзя нормально написать.
Ты какой-то максимально упоротый фанатик. Вангую в тебе студента, который прод не нюхал. Что толку обсуждать язык, на который ноль вакансий? Что толку тебе с того дискорда? Ты там не работаешь и никогда работать не будешь, ты не в США живешь, наркоман.
>Удваиваю, мне в целом похуй на мнение этого клоуна. Мне важно только чтобы у поверхностно читающих этот тредик не сложилось неправильное впечатление. Мы-то с тобой знаем детали языка и его использования и поэтому понимаем почему этот клоун не прав, а анон, который просто зайдёт про язычок почитать, деталей не знает и может реально клоуну поверить.
Честно говоря, я плохо понимаю, почему случайному прохожему может по какой-то причине понравиться эрланг. Я помню, как очень много лет назад поинтересовался, что это за эрланг, на котором ejabberd написан, и пришел к решению — это какая-то странная хуйня, и наверное мне не нужная.
Мне ваш спор напомнил споры мимопроходилов с гуру про лисп, где гуру ловко разъебывали проходящих просто потому, что проходящие были очень плохо знакомы с лиспом. Что, однако, не сильно убеждало прохожего начать писать код из сплошных скобочек.
Даже сейчас, когда я в распределёнке вырос очень сильно, я не совсем уверен в том, что Erlang мне нужен. Встроенный оркестратор — это круто, но проблема разделяемого состояния не решена. Да, можно ответить как разрабы golang: "Don't communicate by sharing memory; instead, share memory by communicating" — но это лишь про другую крайность, а по-хорошему в системе всегда есть потребность в разделяемом состоянии.
И в том числе разрабам дискорда для оптимизиации нетипичного для BEAM способа хранения данных пришлось прибегнуть к помощи внешних инструментов (постгря+редис+кафка), хотя изначально для этого подразумевалось использование Mnesia или какого-то подобного воображаемого инструмента, родного к Erlang (DETS плюс хуй знает что). Тот же Discord категорически не применяет Mnesia, потому что она омерзитольно никак масштабируется.
Теперь внимание вопросы: если работоспособность всей системы зависит от того, не наебнётся ли шардированная постгря, то в чём особенная ценность деревьев супервизии? В чём ценность горячего апгрейда, если 90% ебли заключается в смене схемы постгри? Какая разница в том, какая доля системы сумела восстановиться, если по итогу система в целом неработоспособна, потому что постгря не включена в деревья супервизии?
Как вы понимаете, я уже задавал подобные вопросы нейросетке — она только всплакнула, сказала что-то про "жизнь — страдание, мы все умрём", и ушла в закат.
>Удваиваю, мне в целом похуй на мнение этого клоуна. Мне важно только чтобы у поверхностно читающих этот тредик не сложилось неправильное впечатление. Мы-то с тобой знаем детали языка и его использования и поэтому понимаем почему этот клоун не прав, а анон, который просто зайдёт про язычок почитать, деталей не знает и может реально клоуну поверить.
Честно говоря, я плохо понимаю, почему случайному прохожему может по какой-то причине понравиться эрланг. Я помню, как очень много лет назад поинтересовался, что это за эрланг, на котором ejabberd написан, и пришел к решению — это какая-то странная хуйня, и наверное мне не нужная.
Мне ваш спор напомнил споры мимопроходилов с гуру про лисп, где гуру ловко разъебывали проходящих просто потому, что проходящие были очень плохо знакомы с лиспом. Что, однако, не сильно убеждало прохожего начать писать код из сплошных скобочек.
Даже сейчас, когда я в распределёнке вырос очень сильно, я не совсем уверен в том, что Erlang мне нужен. Встроенный оркестратор — это круто, но проблема разделяемого состояния не решена. Да, можно ответить как разрабы golang: "Don't communicate by sharing memory; instead, share memory by communicating" — но это лишь про другую крайность, а по-хорошему в системе всегда есть потребность в разделяемом состоянии.
И в том числе разрабам дискорда для оптимизиации нетипичного для BEAM способа хранения данных пришлось прибегнуть к помощи внешних инструментов (постгря+редис+кафка), хотя изначально для этого подразумевалось использование Mnesia или какого-то подобного воображаемого инструмента, родного к Erlang (DETS плюс хуй знает что). Тот же Discord категорически не применяет Mnesia, потому что она омерзитольно никак масштабируется.
Теперь внимание вопросы: если работоспособность всей системы зависит от того, не наебнётся ли шардированная постгря, то в чём особенная ценность деревьев супервизии? В чём ценность горячего апгрейда, если 90% ебли заключается в смене схемы постгри? Какая разница в том, какая доля системы сумела восстановиться, если по итогу система в целом неработоспособна, потому что постгря не включена в деревья супервизии?
Как вы понимаете, я уже задавал подобные вопросы нейросетке — она только всплакнула, сказала что-то про "жизнь — страдание, мы все умрём", и ушла в закат.
Эрланг интересен своей концепцией, на этом все. Писать код на акторах и шине событий пиздец как неудобно, вообще ничего не понятно. Вон в голанге сделали, как в эрланге, добавили ранге по каналу, никто этим не пользуется. Классический императивный код с мьютексами легко читать и понимать, в отличие от.
>Классический императивный код с мьютексами легко читать и понимать, в отличие от.
И что ты предлагаешь? Делать Discord на базе одного сервера с node.js? Или у тебя есть какие-то волшебные мьютексы, которые живут сразу на нескольких серверах?
>Ты точно понимаешь, что такое мьютекс?
Я точно понимаю, что такое мьютекс. Ты будешь вопросом на вопрос отвечать?
> проблема разделяемого состояния не решена
Это я не совсем понял. В 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 в этом плане тупо выгоднее и проще.
> проблема разделяемого состояния не решена
Это я не совсем понял. В 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 в этом плане тупо выгоднее и проще.
На словах ты Лев Толстой, а на деле на эликсир нет вакансий. Ты напоминаешь хаскелистов с их охуительными историями про лучший язык.
Если ты про РФ, то да, сейчас Elixir-а практически нет, раньше было больше, но что-то случилось. Был ещё довольно активный рыночек вакансий в Украине, но тоже что-то случилось с ним.
В ЕС и США есть нормальное количество ваканский, в основном удалённая работа, и их в целом достаточно. То есть ваканский меньше чем на Python и Java, например, но и разработчиков не очень много, поэтому я думаю в целом отношение соискатели/вакансии такое же как и в других языках, и найти работу не сложнее чем на них.
Если ты не знаешь английский и не согласен работать удалённо, то я плохо понимаю нахуя ты в айти вообще забыл
Подскажи тогда книги/курсы для вката новичку, пожалуйста. Заебался быть SQL аналитиком, а в пиздон идти желания ещё меньше. Английский средний, могу общаться на бытовом уровне.
>ЕС
Без ворк пермита идешь нахуй.
>США
Без американского паспорта идешь нахуй.
Что и требовалось доказать.
> Без ворк пермита идешь нахуй.
> Без американского паспорта идешь нахуй.
Я понимаю почему ты ошибаешься. На уроках обществознания тебе пока что не рассказали про то что такое ИП, как его открыть в соседней стране по интернету и как октрыть валютный счёт для своего бизнеса. Отношусь к тебе с пониманием, ты просто не знал про это, ведь в пятом классе про это ещё пока не рассказали.
Есть курс от Алексея Матюшкина, я слышал про него хорошие отзывы, но слышал и плохие (не о курсе, а лично об Алексее), так что решай сам.
https://thinknetica.com/pro/elixir_phoenix
Из книжек есть Elixir in Action, Programming Elixir и т.д. Они все незначительно отстают от актуальных версий языка и библиотек, но это не проблема.
Но в 2025 году я могу советовать учить язык только так: открыть редактор кода, доку по elixir (hexdocs.pm/elixir), какой-нибудь чатик или слак по Elixir, и рядом LLM типа chatgpt и начать писать свой проект. Если не знаешь что делать, пишешь сначала в LLM типа "как начать писать проект на Elixir". Если ответ хуйня, пишешь в чатик. Каждый из ответов сверяешь по доке эликсира. Через недельку у тебя должен быть нормальный и рабочий проект.
Но помни, что Elixir это не язык для вката. Здесь очень мало джуновских и интерновских вакансий. Лучше всего будет выучить немного Python/JavaScript, попердеть в стул 1-2 года на работе до того как станешь Middle, а потом подучить Elixir. Пересаживаться с Python и JS на Elixir имеет смысл из-за ЗП (средняя больше в 1.5-2 раза) и из-за ментального здоровья, потому что Python и JS это объективный кал
Проиграл в голос с этого дурачка. Еще раз, медленно, специально для тупых пориджей: без ворк пермита никому ты нахуй там не нуженю Литерали. Свое ИП можешь засунуть в свою тугую задницу. Даже сербы-братушки требуют перекат в течение месяца, всякие бриташки и голашки твое резюме вообще не откроют.
Я мимо проходил. Расскажи если не трудно что за ворк пермит, как его получить и насколько это тяжело при нынешней ситуации?
>>471230
> Расскажи если не трудно что за ворк пермит, как его получить и насколько это тяжело при нынешней ситуации?
Не слушай этого долбоёба, он с самого начала треда пишет сюда какую-то выдуманную хуйню.
Про ворк пермит. То есть разрешение на работу. Оно нужно только если ты устраиваешься в иностранную компанию как сотрудник. Тебе тогда дают рабочую визу и ты можешь переехать в страну где у компании офис. В 2025 году так делают только бигтехи, а компании поменьше нанимают только контрактников, потому что для них это тупо сильно дешевле.
Чтобы стать контрактником, тебе нужно иметь открытый бизнес не в РФ и валютный счёт на который можно получать деньги. Всё это делается за один день в Грузии, Казахстане или Армении (я так делал). В Сербии тоже можно это сделать, но нужен месяц или около того. Для всего этого нужен загран. И ещё есть какие-то сервисы которые это удалённо делают, но я тут не подскажу конкретные.
Потом ты просто устраиваешься как на любую работу в ЕС, и просишь оформить тебя по b2b как контрактника, потом присылаешь им свидетельство о регистрации ИП, номер валютного счёта. Подписываешь контракт и, поздравляю, ты работаешь удалённо на фирму в ЕС. Раз месяц/две недели/неделю ты отправляешь фирме инвойс и они тебе по нему платят на валютный счёт.
Я работаю таким образом уже 5 лет где-то. Полёт нормальный.
Долбоеб тут только ты. Ты сравниваешь рынок пять лет назад и сейчас. Сейчас тебя никто не возьмет на B2B, литерали никто. Будут год искать, занесут кучу бабла агенствам, в итоге возьмут чурку с местным аусвайсом. Рынок труда пошел по пизде, пока ты сидел в своем манямирке, дебил блять.
Найти работу с релокацией. Можешь попробовать прямо сейчас, открываешь линкедин и подаешься.
Да-да, понял тебя, продолжай наблюдение. Нам очень интересно. Я пока ещё инвойсик отправлю.
>>471370
Я пробовал, но это сложнее чем удалёнку. Мне в компаниях открыто говорят, что релокация это просто куча бюрократической душки для них и они думают что им нужен юрист для этого (я-то знаю что это не так, но они почему-то так считают), и ещё им налогов больше платить и т.д. Поэтому на 10 вакансий с удалёнкой я нахожу лишь одну с релокейтом, и там на интервью на меня криво смотрят из-за паспорта. Кароче, после ковида всё стало удалённым, а после 2022 это ещё и сложнее стало конкретно для тех кто из РФ
>Погоди, а на каком языке можно написать сервер, который дёргает 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++).
Мне не нужно его искать — я он и есть, лол.
>Погоди, а на каком языке можно написать сервер, который дёргает 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++).
Мне не нужно его искать — я он и есть, лол.
> DETS
Кстати это полный кал, никому не советую его использовать. Запись туда не durable, не атомарна и ещё и можно проебать запись потому что оно пишется сначала в кэш
> Другое дело, что вот для персистентности лога мне чо использовать в Elixir?
Какого лога? Если у тебя лог событий типа как в EventSourcing/CommandSourcing, то бери тот же тул/сервис что и на другом языке, лол. Ещё есть Commanded, который обёртка для постгри. Если у тебя лог как лог, то пиши туда, куда бы и на другом языке писал: хочешь в файл, хочешь в базу, да куда хочешь кароче.
> То есть, всё связывание сервисов происходит на этапе компиляции и связывается напрямую один сервис с другим, без посредников, без кафок и постгрей
Не понял к чему это. И остальные твои мысли тоже не особо с моим постом связал.
Вообще в целом твой пост какой-то как будто ты свою телегу какую-то пишешь и к моему посту она слабо относится, как и вообще к Elixir. Причём тут редисы, кафки, постгри и вся хуйня, какие ещё гуглы и фейсбуки...
>Лучше всего будет выучить немного Python/JavaScript, попердеть в стул 1-2 года на работе до того как станешь Middle
Питон и жс объективный кал, да, для души пишу скрипты на руби, на эти языки пересаживаться просто больно. :(