1007 Кб, 1500x1500Здравствуй, дорогой анон.
Предыдущий: >> 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. Забугорных вакансий значительно больше и они охотно нанимают разработчиков с опытом. Самое важное качество при найме это не знание самого языка, а софт-скиллы и общее понимание веб-разработки как таковой, так что придётся социализироваться.
Вопросы?
Предыдущий: >> 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. Забугорных вакансий значительно больше и они охотно нанимают разработчиков с опытом. Самое важное качество при найме это не знание самого языка, а софт-скиллы и общее понимание веб-разработки как таковой, так что придётся социализироваться.
Вопросы?
>>351126
Я её написал, я её и сохранил. Правда я не осилил ссылку на предыдущий тренд, но в архиваче, так что похуй
Я её написал, я её и сохранил. Правда я не осилил ссылку на предыдущий тренд, но в архиваче, так что похуй
142 Кб, 948x460главный спонсор треда в СНГ
Здравствуйте!
Я - 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 разработчик!
И я устал извиняться за это...
Я разработчик по праву рождения.
Я проектирую и имплементирую.
Бойтесь!
Здравствуйте!
Я - 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 разработчик!
И я устал извиняться за это...
Я разработчик по праву рождения.
Я проектирую и имплементирую.
Бойтесь!
>>351459
... единственное ПО на эрланге, используемое за пределами эрланг мира.
>Теперь на нём написан RabbitMQ
... единственное ПО на эрланге, используемое за пределами эрланг мира.
>>352098
Да, реально. За доллары сильно проще чем не за доллары. На ~5к можно рассчитывать если миддл. Если сеньор, то как добазаришься, тут нет верхней планки, средняя это 7-10к где-то.
Да, реально. За доллары сильно проще чем не за доллары. На ~5к можно рассчитывать если миддл. Если сеньор, то как добазаришься, тут нет верхней планки, средняя это 7-10к где-то.
а как вы без типов живете? меня вот заебал фронтенд (из за конченных дебилов фронтендеров западных с которыми я не хочу работать в одной компании) хочу свитчнуться на какой-нибудь сложжный язык который любят программисты, хаскель учил но судя по всему вакансий по нему особо нет, на элексире вроде есть вакансси, скалу не хочу потому что там вроде как джаву надо знать, раст не хочу потому что мне кажется он душный какойто
>>353294
Раст не сложный язык. Сложный язык это С++ (сложность не в синтаксисе а в понимании всех нюансов использования).
Раст не сложный язык. Сложный язык это С++ (сложность не в синтаксисе а в понимании всех нюансов использования).
>>353294
о нихуя буквально год назад начали типы добавлять в язык. ну все, походу я к вам в лодку запрыгиваю
о нихуя буквально год назад начали типы добавлять в язык. ну все, походу я к вам в лодку запрыгиваю
>>353301
раст не сложный а душный, мне комьюнити чето не нравится растовское и скандалы какие то вокруг актикса итд
раст не сложный а душный, мне комьюнити чето не нравится растовское и скандалы какие то вокруг актикса итд
>>353304
Двачую. От них ощущение что раст - это вообще самое сложное что они осилили в этой их ит-жизни. И теперь они носятся с ним как с писаной торбой
Это явно хреновый признак. Такое же за яваскриптунами ещё замечал, лет 15 назад
>мне комьюнити чето не нравится растовское
Двачую. От них ощущение что раст - это вообще самое сложное что они осилили в этой их ит-жизни. И теперь они носятся с ним как с писаной торбой
Это явно хреновый признак. Такое же за яваскриптунами ещё замечал, лет 15 назад
>>353317
Патаму что это одни и те же люди
Патаму что это одни и те же люди
>>353330
Ещё чатик в телеге. Ещё сайтик elixirjobs. Ещё elixirforum. Иногда особо одарённые ищут в твитторе
Ещё чатик в телеге. Ещё сайтик elixirjobs. Ещё elixirforum. Иногда особо одарённые ищут в твитторе
>>351068 (OP)
На нём только для сетей чё-то пишут? Или бэкенд тоже?
На нём только для сетей чё-то пишут? Или бэкенд тоже?
>>370278
Вебмакака как всегда неспособна рассматривать технологии иначе чем через призму пригодности для написания крудов.
Вебмакака как всегда неспособна рассматривать технологии иначе чем через призму пригодности для написания крудов.
>>370278
Из того что я видел в вакансиях это бэкэнды, вебсайты (любые, от ecommerce до стриминга видео и приложений), телеком, сервисы, брокеры, ML, нейросети, IoT, алготрейдинг, боты в телеге
Ну ты примерно понял
Из того что я видел в вакансиях это бэкэнды, вебсайты (любые, от ecommerce до стриминга видео и приложений), телеком, сервисы, брокеры, ML, нейросети, IoT, алготрейдинг, боты в телеге
Ну ты примерно понял
>>372575
Ясно. Кароч гиковский язык для нитакусей.
Ясно. Кароч гиковский язык для нитакусей.
> Вопросы?
Да какие тут вопросы, ещё более мёртвая вещь чем Ruby и Rails
И явно не для вкатунов, не представляю как на нём работу искать, очень редко на hh может мелькнуть вакансия
>>373375
И почему это плохо?
Так и не ищи на hh. Elixir это не про работу в РФ. Выше скинули сайты, где надо искать работу, и там дохуя вариантов на любой вкус и цвет
> И явно не для вкатунов
И почему это плохо?
> не представляю как на нём работу искать, очень редко на hh может мелькнуть вакансия
Так и не ищи на hh. Elixir это не про работу в РФ. Выше скинули сайты, где надо искать работу, и там дохуя вариантов на любой вкус и цвет
483 Кб, 1080x2117>>351068 (OP)
Десяток вакансий за последний год. Да на дельфи работы больше.
>Вакансии на рынке РФ существуют, искать можно на hhрю или в чатиках в телеге t.me/proelixir.
Десяток вакансий за последний год. Да на дельфи работы больше.
>>351068 (OP)
Вау, прикольный язык так-то оказывается. Чисто пофаниться можно смены в 1с вечерком, идеальный варик.
Вау, прикольный язык так-то оказывается. Чисто пофаниться можно смены в 1с вечерком, идеальный варик.
>>374808
Не все постят с хэштегом, смотри в закрепе в сообщениях. Ну и да, разрабов-то тоже мало, поэтому норм что вакансий мало
Не все постят с хэштегом, смотри в закрепе в сообщениях. Ну и да, разрабов-то тоже мало, поэтому норм что вакансий мало
Эликсир это база, сынки.
>>351068 (OP)
Хочу сделать табличку, в которую клиенты компании будут ходить и смотреть данные из нашей БД. Чтобы была сортировка, фильтрация по столбцам, поиск, выбор колонок и т.д.
С одной стороны хочется, чтобы писать кода надо было минимум, потому что люди, которые будут это в будущем поддерживать, скорее всего, далеки от современной веб-разработки. С другой хочется, чтобы всё было прозрачно, а не спрятано за кучей слоёв фреймворка, чтобы мне одному проще было в этом разобраться.
Собственно, я придумал только два варианта:
1) Elixir + Phoenix LiveView. Не уверен, насколько мало надо писать в итоге кода, но выглядит как то, что мне нужно. Проблема в том, что кроме меня в эликсире вряд ли кто-то захочет разбираться.
2) Go. Просто в тупую получать запрос и генерить HTML в ответ. Максимально прозрачно, но много кода. Зато если что, разрабов будет проще найти.
Есть ещё какие-то варианты?
Хочу сделать табличку, в которую клиенты компании будут ходить и смотреть данные из нашей БД. Чтобы была сортировка, фильтрация по столбцам, поиск, выбор колонок и т.д.
С одной стороны хочется, чтобы писать кода надо было минимум, потому что люди, которые будут это в будущем поддерживать, скорее всего, далеки от современной веб-разработки. С другой хочется, чтобы всё было прозрачно, а не спрятано за кучей слоёв фреймворка, чтобы мне одному проще было в этом разобраться.
Собственно, я придумал только два варианта:
1) Elixir + Phoenix LiveView. Не уверен, насколько мало надо писать в итоге кода, но выглядит как то, что мне нужно. Проблема в том, что кроме меня в эликсире вряд ли кто-то захочет разбираться.
2) Go. Просто в тупую получать запрос и генерить HTML в ответ. Максимально прозрачно, но много кода. Зато если что, разрабов будет проще найти.
Есть ещё какие-то варианты?
>>406487
Это дохлый тред, если ты не понял.
Я бы на твоём месте отталкивался от этого. Эликсир, кмк, язык отличный, но слишком нишевый, чтобы с ним можно было уверенно экспериментировать в профессиональной среде, потому как сотрудников ты действительно не найдёшь.
Забеги на elixirforum.com, там достаточно лояльное сообщество, спроси про свои беды. Тебя направят, помогут определиться.
Это дохлый тред, если ты не понял.
> Зато если что, разрабов будет проще найти.
Я бы на твоём месте отталкивался от этого. Эликсир, кмк, язык отличный, но слишком нишевый, чтобы с ним можно было уверенно экспериментировать в профессиональной среде, потому как сотрудников ты действительно не найдёшь.
Забеги на elixirforum.com, там достаточно лояльное сообщество, спроси про свои беды. Тебя направят, помогут определиться.
>>407237
Дохлая это твоя мать
>>406487
Эликсир проще чем руби и питон, там разбираться не нужно. Эликсир с нуля учится за две недели. В год можно изучить до 26 эликсиров.
https://hexdocs.pm/kaffy/readme.html
https://hexdocs.pm/torch/readme.html
> Это дохлый тред, если ты не понял.
Дохлая это твоя мать
>>406487
>Проблема в том, что кроме меня в эликсире вряд ли кто-то захочет разбираться.
Эликсир проще чем руби и питон, там разбираться не нужно. Эликсир с нуля учится за две недели. В год можно изучить до 26 эликсиров.
> Хочу сделать табличку, в которую клиенты компании будут ходить и смотреть данные из нашей БД. Чтобы была сортировка, фильтрация по столбцам, поиск, выбор колонок и т.д.
https://hexdocs.pm/kaffy/readme.html
https://hexdocs.pm/torch/readme.html
Здравствуйте. Хочу для себя, обучения ради обучения, потыкать эликсир и переписать свою программу на питоне на Elixir. Изначально на питоне хотел сделать прототип, чтобы переписать потом, но так уж вышло, что сделал полноценную программу, но цели всё равно достигнуть хочу. Так вот, программа запускает отдельные процессы через multiprocessing, которые могут работать сутками, а то и больше, общение идёт через mutliprocessing.Pipe через мои "сообщения", если угодно, а именно датаклассы с параметрами разными. Хочу попробовать переписать на эликсир её. Подходит ли этот язык для таких "долго работающих" задач и удобное ли взаимодействие с этими процессами, отслеживание упало/не упало, обработкак ошибок, запросы по сети делать на сайты, доступ к БД, файлой системе?
Хочу сделать запуск процедур по расписанию точково (как scheduled сообщения в телеге) - как это сделать в эликсирчике с фениксом?
реббит с scheduled tasks плагином не варик так как оно сносно работает только с датами в скором будущем + потенциально проебывать некоторые запуски не оч хорошо поэтому нужна запись в базу
реббит с scheduled tasks плагином не варик так как оно сносно работает только с датами в скором будущем + потенциально проебывать некоторые запуски не оч хорошо поэтому нужна запись в базу
>>351068 (OP)
Если оформлять вкат в эликсир здорового человека - по-хорошему нужно освоить эрланг для начала? 5 лет назад внезапно столкнулся на работе с эрлангом, рефакторил старый сервер, было сложно пердолиться, но парадигма языка запала в душу с тех пор. С элексиром я так понимаю карьерные перспективы становятся кратно выше.
Если оформлять вкат в эликсир здорового человека - по-хорошему нужно освоить эрланг для начала? 5 лет назад внезапно столкнулся на работе с эрлангом, рефакторил старый сервер, было сложно пердолиться, но парадигма языка запала в душу с тех пор. С элексиром я так понимаю карьерные перспективы становятся кратно выше.
>>441484
Да, подходит больше чем Elixir, с ним не нужны хаки типа multiprocessing, не нужнен ебучий async/await, просто пишешь как обычно пишут на Elixir и всё асинхронность и многопоточность будет из коробки
>>441520
Лучше всего через job queue какой-нибудь. Или можно на коленке: класть в базу что нужно в такое-то время отправить сообщение. и вешать Process.send_after. На старте и, например, раз в день, читать из базы и обновлять таймеры
>>441632
Отдельно учить Erlang не нужно, он сам учится в процессе освоения Elixir, различия будут только в не очень важных деталях типа там синтаксиса и немного других модулей. Кароче, учи сразу Elixir и не парься. Работы на Elixir больше, это факт, особенно если ты джун/миддл. На Erlang работа есть только для очень опытных, и чаще всего в легаси проектах
> Подходит ли этот язык для таких "долго работающих" задач и удобное ли взаимодействие с этими процессами, отслеживание упало/не упало, обработкак ошибок, запросы по сети делать на сайты, доступ к БД, файлой системе?
Да, подходит больше чем Elixir, с ним не нужны хаки типа multiprocessing, не нужнен ебучий async/await, просто пишешь как обычно пишут на Elixir и всё асинхронность и многопоточность будет из коробки
>>441520
> Хочу сделать запуск процедур по расписанию точково (как scheduled сообщения в телеге) - как это сделать в эликсирчике с фениксом?
Лучше всего через job queue какой-нибудь. Или можно на коленке: класть в базу что нужно в такое-то время отправить сообщение. и вешать Process.send_after. На старте и, например, раз в день, читать из базы и обновлять таймеры
>>441632
Отдельно учить Erlang не нужно, он сам учится в процессе освоения Elixir, различия будут только в не очень важных деталях типа там синтаксиса и немного других модулей. Кароче, учи сразу Elixir и не парься. Работы на Elixir больше, это факт, особенно если ты джун/миддл. На Erlang работа есть только для очень опытных, и чаще всего в легаси проектах
>>465281
Больше чем Python, я имел в виду.
В питоне нет многопоточности и асинхронности нормальной. В Elixir это всё сильно проще и удобнее
> Да, подходит больше чем Elixir
Больше чем Python, я имел в виду.
В питоне нет многопоточности и асинхронности нормальной. В Elixir это всё сильно проще и удобнее
>>351068 (OP)
Я попросил нейросеть написать сервис на ерланге и то же самое на эликсире. Если в эрланге есть математическая красота, то эликсир какой-то всратый, будто эрланг измазали джаваскриптом. Впрочем, вкатиться импосибл в оба, на рынке полторы вакансии с требованиями 5+ лет опыта.
Я попросил нейросеть написать сервис на ерланге и то же самое на эликсире. Если в эрланге есть математическая красота, то эликсир какой-то всратый, будто эрланг измазали джаваскриптом. Впрочем, вкатиться импосибл в оба, на рынке полторы вакансии с требованиями 5+ лет опыта.
>>351068 (OP)
Все равно, что пытаться найти работу на Erlang, Haskell или OCaml. Смысл лезть в полумертвые языки, где тулинг, библиотеки и фреймворки остановились в развитии на уровне начала 00-х годов? Тут даже на популярном стеке проблематично найти работу, что уж говорить о такой экзотике
>Чтобы стать джуном на эликсире
Все равно, что пытаться найти работу на Erlang, Haskell или OCaml. Смысл лезть в полумертвые языки, где тулинг, библиотеки и фреймворки остановились в развитии на уровне начала 00-х годов? Тут даже на популярном стеке проблематично найти работу, что уж говорить о такой экзотике
>>465565
Как раз во всякой дохляди должно быть проще, потому что там не то что волков и упругих зумеров, там вообще желающих с этим возиться даже предпенсионного возраста хуй найдёшь. Поэтому на такое обычно берут всех, кто не совсем тупой, имеет хоть сколько-то серьёзный опыт (пусть даже сраных петпроектов) и замотивирован развиваться дальше.
>даже на популярном стеке
Как раз во всякой дохляди должно быть проще, потому что там не то что волков и упругих зумеров, там вообще желающих с этим возиться даже предпенсионного возраста хуй найдёшь. Поэтому на такое обычно берут всех, кто не совсем тупой, имеет хоть сколько-то серьёзный опыт (пусть даже сраных петпроектов) и замотивирован развиваться дальше.
Мне недавно попался gleam, по доке понравился. Оссобено его аналог do синтаксиса для монад. Только отсутствие if, в пользу match true false -> шиза. За erlang, elixir не разбираюсь, просто gleam в beam таргетится. Может у ветеранов акторных войн есть мнение.
>>465580
Это либо переписывание интернет магазинов с руби он реилс на эликсир и феникс, либо, если мы говорим про эрланг, то в 99% случаев это телеком где эрланг вообще сбоку и нужен как клей для модулей на сишке. Вакансий так же полторы штуки и залетные нахуй не нужны. Окамл хз где используют кроме как в джейн стрит где от него потихоньку отказываются. Скала сдохла. Хаскелл тупо академическая залупа. Была вакансия в тиньке даже, но там искали яйцеголового любителя фп, чтобы он какой-то рулер писал для кредитования. Еще в барклейс искали хаскеллиста. Это настолько нишевая и точечная хуйня, что желающих попасть будет побольше чем на какой-нибудь гоулэнг, т.к. у тебя рили вакансий - раз два и обчелся
>там вообще желающих с этим возиться даже предпенсионного возраста хуй найдёшь
Это либо переписывание интернет магазинов с руби он реилс на эликсир и феникс, либо, если мы говорим про эрланг, то в 99% случаев это телеком где эрланг вообще сбоку и нужен как клей для модулей на сишке. Вакансий так же полторы штуки и залетные нахуй не нужны. Окамл хз где используют кроме как в джейн стрит где от него потихоньку отказываются. Скала сдохла. Хаскелл тупо академическая залупа. Была вакансия в тиньке даже, но там искали яйцеголового любителя фп, чтобы он какой-то рулер писал для кредитования. Еще в барклейс искали хаскеллиста. Это настолько нишевая и точечная хуйня, что желающих попасть будет побольше чем на какой-нибудь гоулэнг, т.к. у тебя рили вакансий - раз два и обчелся
>>465371
Асинхронности нормальной нет. async/await уже весь мир, включая самих питонистов, признал как полный кал. Посмотрите на Elixir, Go, Java, Rust, там везде нормальные гринтреды/csp.
Многопоточности нет. multiprocessing это хак, который с async/await никак не интегрирован. А многопоточные wsgi серверы это позор уровня PHP. Например, если у меня один процесс будет набит работой, а другой будет пустой, то рантайм автоматически их не сбалансирует и не распараллелит, а это надо будет делать разработчику
Асинхронности нормальной нет. async/await уже весь мир, включая самих питонистов, признал как полный кал. Посмотрите на Elixir, Go, Java, Rust, там везде нормальные гринтреды/csp.
Многопоточности нет. multiprocessing это хак, который с async/await никак не интегрирован. А многопоточные wsgi серверы это позор уровня PHP. Например, если у меня один процесс будет набит работой, а другой будет пустой, то рантайм автоматически их не сбалансирует и не распараллелит, а это надо будет делать разработчику
>>465523
Это в РФ, смотри Европу и США, там охотно нанимают на релокейт из любых концов мира. На моём проекте больше половины разрабов это СНГ и Индия/Китай (примерно поровну каждых). Спрос на разрабов есть
> на рынке полторы вакансии
Это в РФ, смотри Европу и США, там охотно нанимают на релокейт из любых концов мира. На моём проекте больше половины разрабов это СНГ и Индия/Китай (примерно поровну каждых). Спрос на разрабов есть
>>465565
Ну тут ты не прав. У Elixir пиздатейший тулинг, тот же mix, например, сильно удобнее чем даже cargo. А фреймворки, посмотри на Phoenix, например. Они первыми сделали LiveView, там очень сильный PubSub, вот сейчас завозят PhoenixSync, который типа eventually consistent database sync сразу на клиенты.
Библиотеки тоже на любой вкус. Пиши что тебе нужно, я подскажу либу
> тулинг, библиотеки и фреймворки остановились в развитии на уровне начала 00-х годов
Ну тут ты не прав. У Elixir пиздатейший тулинг, тот же mix, например, сильно удобнее чем даже cargo. А фреймворки, посмотри на Phoenix, например. Они первыми сделали LiveView, там очень сильный PubSub, вот сейчас завозят PhoenixSync, который типа eventually consistent database sync сразу на клиенты.
Библиотеки тоже на любой вкус. Пиши что тебе нужно, я подскажу либу
>>465661
Нихуя, я думаю на Elixir e-commerce вообще не очень популярен. Большая часть проектов на Elixir это всякие интерактивные вебсайты, стриминги, чатики, какие-нибудь бэкенды. Ещё Elixir в IoT и ML присутствует
Это было правдой лет 20 назад, когда всё писали на C/C++ и мультитрединг там был очень душный, поэтому параллелили через Erlang. Сейчас на Erlang есть и телеком, и вон много всякой IO-bound хуйни пишут типа EMQX, бд типа CouchDB, тот же RabbitMQ. Но сейчас уже Erlang и правда больше легаси и вытесняется Elixir-ом
> Это либо переписывание интернет магазинов с руби он реилс на эликсир и феникс
Нихуя, я думаю на Elixir e-commerce вообще не очень популярен. Большая часть проектов на Elixir это всякие интерактивные вебсайты, стриминги, чатики, какие-нибудь бэкенды. Ещё Elixir в IoT и ML присутствует
> если мы говорим про эрланг, то в 99% случаев это телеком где эрланг вообще сбоку и нужен как клей для модулей на сишке
Это было правдой лет 20 назад, когда всё писали на C/C++ и мультитрединг там был очень душный, поэтому параллелили через Erlang. Сейчас на Erlang есть и телеком, и вон много всякой IO-bound хуйни пишут типа EMQX, бд типа CouchDB, тот же RabbitMQ. Но сейчас уже Erlang и правда больше легаси и вытесняется Elixir-ом
>>465611
Gleam норм тема. Пока что он слишком сырой для прода, там не хватает экосистемы и всякие моменты внутри языка пока ещё не готовы (вроде статической типизации акторов).
Поэтому это риск, ведь не факт что Gleam успеет обрасти экосистемой раньше чем у Elixir появится статическая типизация.
Gleam норм тема. Пока что он слишком сырой для прода, там не хватает экосистемы и всякие моменты внутри языка пока ещё не готовы (вроде статической типизации акторов).
Поэтому это риск, ведь не факт что Gleam успеет обрасти экосистемой раньше чем у Elixir появится статическая типизация.
>>466117
Не нужен. Все системы на шине событий превращаются в говно.
Оу май гад соу мач базворд ориентед девелопмент!
Вангую все закончится еще одним KV хранилищем, снова.
>PubSub
Не нужен. Все системы на шине событий превращаются в говно.
>eventually consistent database sync
Оу май гад соу мач базворд ориентед девелопмент!
Вангую все закончится еще одним KV хранилищем, снова.
>>466117
Хотя бы IDE нормальную завезли уровня IntelliJ IDEA?
Кто из крупных игроков вкладывается в развитие тулинга и библиотек/фреймворков в эликсире? Именно крупные компании, которые разрабатывают и поддерживают эти решения, а не ноунейм пердольки, которые выпукивают свои поделки на гитхаб
>Ну тут ты не прав. У Elixir пиздатейший тулинг
Хотя бы IDE нормальную завезли уровня IntelliJ IDEA?
>Библиотеки тоже на любой вкус
Кто из крупных игроков вкладывается в развитие тулинга и библиотек/фреймворков в эликсире? Именно крупные компании, которые разрабатывают и поддерживают эти решения, а не ноунейм пердольки, которые выпукивают свои поделки на гитхаб
>>466119
Последний раз, когда я тыкал Эрланг, там даже нормальной поддержки со стороны IDE не было. Фанатики убеждали меня, что IDE это фу-фу и норм писать в обычном текстовом редакторе, временами переключаясь в терминал и пытаться скомпилировать код, чтобы получить сообщения об ошибке и затем идти обратно в редактор, чтобы их пофиксать. Про интеграцию со всякими дебагерами, запуском приложения и т.д. и т.п. я не говорю - этого нет
На эрланге все саксесс сторис которые я видел это демонвейр с их сервером для калловдути и прочие поделки из мира телекома где эрланг вообще сбоку и нужен тупо как клей. С приходом гоулэнга и клауд нейтив в виде контейнеров и кубера эрланг нахуй выкинули.
А эликсир это как раз попытка влезть на поляну руби и рор с его интернет-магазинами и сайтами визитками
Последний раз, когда я тыкал Эрланг, там даже нормальной поддержки со стороны IDE не было. Фанатики убеждали меня, что IDE это фу-фу и норм писать в обычном текстовом редакторе, временами переключаясь в терминал и пытаться скомпилировать код, чтобы получить сообщения об ошибке и затем идти обратно в редактор, чтобы их пофиксать. Про интеграцию со всякими дебагерами, запуском приложения и т.д. и т.п. я не говорю - этого нет
На эрланге все саксесс сторис которые я видел это демонвейр с их сервером для калловдути и прочие поделки из мира телекома где эрланг вообще сбоку и нужен тупо как клей. С приходом гоулэнга и клауд нейтив в виде контейнеров и кубера эрланг нахуй выкинули.
А эликсир это как раз попытка влезть на поляну руби и рор с его интернет-магазинами и сайтами визитками
>>466446
Ты из каменного века пришёл? В твоём мире колесо изобрели или пока нет? Какие нахуй IntelliJ IDEA, ты ебанулся? Весь мир пишет весь код в VSCode или Cursor, которые тупо пользуются language server-ом (для эликсира такой есть)
Нихуя не понял как это с качеством связано. Я смотрю на Java и вижу что там много корпоративного кала, который меняется от версии к версии и нихуя стабильного там нет. И я смотрю на Elixir, где есть куча качественного софта, большинство из которого крутится в реальных продах и ежедневно улучшается этими компаниями
> Хотя бы IDE нормальную завезли уровня IntelliJ IDEA?
Ты из каменного века пришёл? В твоём мире колесо изобрели или пока нет? Какие нахуй IntelliJ IDEA, ты ебанулся? Весь мир пишет весь код в VSCode или Cursor, которые тупо пользуются language server-ом (для эликсира такой есть)
> Кто из крупных игроков вкладывается в развитие тулинга и библиотек/фреймворков в эликсире? Именно крупные компании, которые разрабатывают и поддерживают эти решения, а не ноунейм пердольки, которые выпукивают свои поделки на гитхаб
Нихуя не понял как это с качеством связано. Я смотрю на Java и вижу что там много корпоративного кала, который меняется от версии к версии и нихуя стабильного там нет. И я смотрю на Elixir, где есть куча качественного софта, большинство из которого крутится в реальных продах и ежедневно улучшается этими компаниями
>>466447
Не знаю, может из того тугого очка, откуда ты на мир смотришь, так и кажется, но у меня дохуя лет опыта в экосистеме и это нихуя не так. Хочешь саксесс стори на Elixir? Дискорд. Дальше продолжать или может хотя бы погуглишь прежде чем здесь писать своё ахуенно полезное мнение?
> А эликсир это как раз попытка влезть на поляну руби и рор с его интернет-магазинами и сайтами визитками
Не знаю, может из того тугого очка, откуда ты на мир смотришь, так и кажется, но у меня дохуя лет опыта в экосистеме и это нихуя не так. Хочешь саксесс стори на Elixir? Дискорд. Дальше продолжать или может хотя бы погуглишь прежде чем здесь писать своё ахуенно полезное мнение?
>>466160
Это не про шину событий, а про PubSub, типа как MQTT, только без стороннего сервера, а прям внутри системы. Очень удобно, так как тупо оптимизирует весь поллинг в местах, где нужен синк всяких вещей которые меняют разные клиенты (типа там чатов или стримов или чего-то такого)
> Не нужен. Все системы на шине событий превращаются в говно.
Это не про шину событий, а про PubSub, типа как MQTT, только без стороннего сервера, а прям внутри системы. Очень удобно, так как тупо оптимизирует весь поллинг в местах, где нужен синк всяких вещей которые меняют разные клиенты (типа там чатов или стримов или чего-то такого)
>>466160
Мимо родной, почитай хотя бы доку. Суть PhoenixSync такая: ты можешь считай подписаться на SQL запрос в постгрю. Ты типа этот запрос шлёшь в базу и тебе возвращается бесконечный стрим, внутри которого лежат все изменения по этому запросу. Пока что оно работает только на очень тупых запросах и плоских таблицах, но в целом это считай автоматическая инвалидация кэшей. Где ты такое ещё видел?
> Вангую все закончится еще одним KV хранилищем, снова.
Мимо родной, почитай хотя бы доку. Суть PhoenixSync такая: ты можешь считай подписаться на SQL запрос в постгрю. Ты типа этот запрос шлёшь в базу и тебе возвращается бесконечный стрим, внутри которого лежат все изменения по этому запросу. Пока что оно работает только на очень тупых запросах и плоских таблицах, но в целом это считай автоматическая инвалидация кэшей. Где ты такое ещё видел?
>>466819
Очевидно, ты не понимаешь, что такое IDE и поддержка языка программирования в нем. Твой вскод обычный текстовый редактор. lsp вообще не решает проблем про которые я говорил. Автокомплит, поиск по коду и прочие интеграции в вскоде не реализованы
>Весь мир пишет весь код в VSCode или Cursor, которые тупо пользуются language server-ом (для эликсира такой есть)
Очевидно, ты не понимаешь, что такое IDE и поддержка языка программирования в нем. Твой вскод обычный текстовый редактор. lsp вообще не решает проблем про которые я говорил. Автокомплит, поиск по коду и прочие интеграции в вскоде не реализованы
>>466827
Представил картинку с ртом в говне.
Удобно это сигналы, потому что они локальны и конкретны. Можно строить иерархии сигналов, можно делать условия передачи сигнала, можно строить сетевые экраны и транспорты которые работают с сигналами из какой-то области видимости. Можно делать что угодно, блядь. И это наверняка в ерланге уже давно реализовано. А пабсап. Ну. Что-то из мира ООП-кала с протёкшей абстракцией, да?
Лучше бы они придумали что-то чтобы эликсир в си компилировался. Вот это полезно.
> Очень удобно,
Представил картинку с ртом в говне.
Удобно это сигналы, потому что они локальны и конкретны. Можно строить иерархии сигналов, можно делать условия передачи сигнала, можно строить сетевые экраны и транспорты которые работают с сигналами из какой-то области видимости. Можно делать что угодно, блядь. И это наверняка в ерланге уже давно реализовано. А пабсап. Ну. Что-то из мира ООП-кала с протёкшей абстракцией, да?
Лучше бы они придумали что-то чтобы эликсир в си компилировался. Вот это полезно.
>>466119
Тут проблема даже не в том, что он легаси, сколько в том, что и Erlang, и Elixir очень нишевый и на них очень мало проектов создаётся. Чисто в сравнениюю с проектами на том же Python, которых в тысячу раз больше.
>>466908
Дык это не полинг, это пушинг.
С другой стороны, я согласен, что шина событий и централизированные KV-зранилища — это ебаный рак. Каждый раз, когда кто-то делает распределённую систему, выпрыгивает тимлид-архитектор и орёт "нужно централизованное ACID-complaint хранилище, по best practice". Какого хуя вообще в Elixir делает постгря? Вот что хотелось бы спросить.
По сути писание системы на Elixir+Phoenix+PostgreSQL делает её заменой для Ruby+RoR+PostgreSQL — "заменой" в том плане, что Ellxir намного быстрее и масштабируемее. По производительности и модели выполнения оно ближе к Go+Gin+PostgreSQL при том допущении, что у вас один хуй централизированная параша, а отдельные распределённые сервисы вы будете оркестрировать каким-нибудь кубернетом.
>Но сейчас уже Erlang и правда больше легаси и вытесняется Elixir-ом
Тут проблема даже не в том, что он легаси, сколько в том, что и Erlang, и Elixir очень нишевый и на них очень мало проектов создаётся. Чисто в сравнениюю с проектами на том же Python, которых в тысячу раз больше.
>>466908
>Иными словами, дергаем запрос по кд. Зумеры изобрели поллинг.
Дык это не полинг, это пушинг.
С другой стороны, я согласен, что шина событий и централизированные KV-зранилища — это ебаный рак. Каждый раз, когда кто-то делает распределённую систему, выпрыгивает тимлид-архитектор и орёт "нужно централизованное ACID-complaint хранилище, по best practice". Какого хуя вообще в Elixir делает постгря? Вот что хотелось бы спросить.
По сути писание системы на Elixir+Phoenix+PostgreSQL делает её заменой для Ruby+RoR+PostgreSQL — "заменой" в том плане, что Ellxir намного быстрее и масштабируемее. По производительности и модели выполнения оно ближе к Go+Gin+PostgreSQL при том допущении, что у вас один хуй централизированная параша, а отдельные распределённые сервисы вы будете оркестрировать каким-нибудь кубернетом.
>>466889
Реализованы. Прочие интеграции это какие? Дебаггер есть в elixir-ls. Интеграция с iex есть в VSCode через плагин. Ты по сути-то напиши, что тебе нужно
> Автокомплит, поиск по коду
Реализованы. Прочие интеграции это какие? Дебаггер есть в elixir-ls. Интеграция с iex есть в VSCode через плагин. Ты по сути-то напиши, что тебе нужно
>>466907
Я не понимаю тебя, долбоёб, ты что в этом треде забыл? Есть сигналы, есть телеметрия, есть эвенты, есть пабсаб, есть хуйня на любой вкус и цвет.
Твой аргумент-то в чём? В том что тебе пабсаб не нравится? Так и не пользуйся, дегенерат, возьми любую другую хуйню. Мне лично на пабсаб тотально похуй, у меня нет никаких чувств к нему, я подключаю его когда он решает мне вполне конкретные проблемы. Я тебе, ебанат, не предлагаю ебаным пабсабом решать каждую проблему распределённого мира.
Пошёл нахуй из треда обратно на питоне писать
Я не понимаю тебя, долбоёб, ты что в этом треде забыл? Есть сигналы, есть телеметрия, есть эвенты, есть пабсаб, есть хуйня на любой вкус и цвет.
Твой аргумент-то в чём? В том что тебе пабсаб не нравится? Так и не пользуйся, дегенерат, возьми любую другую хуйню. Мне лично на пабсаб тотально похуй, у меня нет никаких чувств к нему, я подключаю его когда он решает мне вполне конкретные проблемы. Я тебе, ебанат, не предлагаю ебаным пабсабом решать каждую проблему распределённого мира.
Пошёл нахуй из треда обратно на питоне писать
>>467921
Мой аргумент в том, что этот кал идёт по пути развития пхп - прямо нахуй в бездну. Вместо допиливания реально важного - быстродействия, занимаются какой-то хуйней.
Мой аргумент в том, что этот кал идёт по пути развития пхп - прямо нахуй в бездну. Вместо допиливания реально важного - быстродействия, занимаются какой-то хуйней.
>>467941
Ты меня заебал, я тебя в другой тред послал, потому что ты пишешь хуйню про которую вообще нихуя не знаешь. Реально, твоё мнение будет очень ценным в тредике про питон или по какому там ещё игрушечному языку ты осилил "введение для чайников" прочитать. Сюда свои высеры не пиши.
Ну вот просто посмотрим на хуйню, которую ты написал и оценим насколько ты прав чисто чтобы ты сам понял насколько твои высеры тут никому нахуй не нужны.
Во-первых, PubSub-ом для Phoenix и разработкой рантайма занимаются совершенно разные люди. Это вещи разного уровня, внутри там разные технологии, совершенно разная экспертиза требуется.
Во-вторых, про быстродействие, в релизах OTP регулярно происходят оптимизации. С того как в OTP 24 появился JIT, каждую версию они его допиливают, вводят статическую типизацию на уровне Core Erlang (один из IR-ов), чтобы JIT генерировал как можно более быстрый нативный код.
В-третьих, твои набросы на PubSub это просто постная хуйня. Если ты не знаешь как пользоваться PubSub-ом и в каких задачах его применяют, то ты автоматически идёшь нахуй. Конечно, ебать, если ты на PubSub писал движок для сетевой видеоигры, ты насосал хуёв c PubSub-ом, но ты их насосал не потому что PubSub хуйня (он как раз не хуйня), а потому что ты долбоёб конченный применил технологию там, где она нахуй не нужна и для чего она не подходит. Если у тебя между ушей сейчас какие-нибудь две клетки мозга замкнутся, я думаю ты поймёшь что я имею в виду, но, к сожалению, шансы очень нахуй не велики
Ты меня заебал, я тебя в другой тред послал, потому что ты пишешь хуйню про которую вообще нихуя не знаешь. Реально, твоё мнение будет очень ценным в тредике про питон или по какому там ещё игрушечному языку ты осилил "введение для чайников" прочитать. Сюда свои высеры не пиши.
Ну вот просто посмотрим на хуйню, которую ты написал и оценим насколько ты прав чисто чтобы ты сам понял насколько твои высеры тут никому нахуй не нужны.
> Вместо допиливания реально важного - быстродействия, занимаются какой-то хуйней.
Во-первых, PubSub-ом для Phoenix и разработкой рантайма занимаются совершенно разные люди. Это вещи разного уровня, внутри там разные технологии, совершенно разная экспертиза требуется.
Во-вторых, про быстродействие, в релизах OTP регулярно происходят оптимизации. С того как в OTP 24 появился JIT, каждую версию они его допиливают, вводят статическую типизацию на уровне Core Erlang (один из IR-ов), чтобы JIT генерировал как можно более быстрый нативный код.
В-третьих, твои набросы на PubSub это просто постная хуйня. Если ты не знаешь как пользоваться PubSub-ом и в каких задачах его применяют, то ты автоматически идёшь нахуй. Конечно, ебать, если ты на PubSub писал движок для сетевой видеоигры, ты насосал хуёв c PubSub-ом, но ты их насосал не потому что PubSub хуйня (он как раз не хуйня), а потому что ты долбоёб конченный применил технологию там, где она нахуй не нужна и для чего она не подходит. Если у тебя между ушей сейчас какие-нибудь две клетки мозга замкнутся, я думаю ты поймёшь что я имею в виду, но, к сожалению, шансы очень нахуй не велики
>>467975
Ещё мочератору поплачь что в твоём треде срут и постят неприятное, хех
Ага, так же как дистры хрюникса пишут разные люди которые не могут хоть как-то собраться и найти компромисы. Итог очевиден.
А ясно, вопросов больше не имею. Дебичи думают что они такие же гении как в гугле с их V8. Типы нужно на уровне языка внедрять, какими угодно способами, чтобы не пилить безумное говнище на жите которое совершенно точно работать не будет.
Пабсаб применяют говноеды которым норм протёкшие абстракции хавать. Больше тут нечего сказать.
Уверен, ты уже замечал какие-то неприятные моменты в пабсабе, именно по этому у тебя так разорвалась твоя говноедская жопа. Ты знаешь что я прав, а ты поел говна.
> Ты меня заебал, я тебя в другой тред послал,
Ещё мочератору поплачь что в твоём треде срут и постят неприятное, хех
> Во-первых, PubSub-ом для Phoenix и разработкой рантайма занимаются совершенно разные люди.
Ага, так же как дистры хрюникса пишут разные люди которые не могут хоть как-то собраться и найти компромисы. Итог очевиден.
> С того как в OTP 24 появился JIT,
> вводят статическую типизацию на уровне Core Erlang (один из IR-ов),
А ясно, вопросов больше не имею. Дебичи думают что они такие же гении как в гугле с их V8. Типы нужно на уровне языка внедрять, какими угодно способами, чтобы не пилить безумное говнище на жите которое совершенно точно работать не будет.
> В-третьих, твои набросы на PubSub это просто постная хуйня. Если ты не знаешь как пользоваться PubSub-ом и в каких задачах его применяют, то ты автоматически идёшь нахуй.
Пабсаб применяют говноеды которым норм протёкшие абстракции хавать. Больше тут нечего сказать.
> Если у тебя между ушей сейчас какие-нибудь две клетки мозга замкнутся, я думаю ты поймёшь что я имею в виду, но, к сожалению, шансы очень нахуй не велики
Уверен, ты уже замечал какие-то неприятные моменты в пабсабе, именно по этому у тебя так разорвалась твоя говноедская жопа. Ты знаешь что я прав, а ты поел говна.
>>467995
Начнём с того что ты писал что надо сделать компилятор в C. Эта хуйня уже была для Erlang (до R1 версии, если я не ошибаюсь) и работало ультрахуёво из-за того что разные компиляторы и под разные системы компилируют совсем по-разному и из-за того что это было тупо медленно, так как было две компиляции вместо одной. И ещё была такая система как HiPE, которая AOT компилировала в натив через LLVM, и это тоже был кал. Так что тут ты проебался и нихуя знаешь
Далее, ты написал что типы не внедряют. Но под Elixir и Erlang есть статическая типизация в виде Dialyzer (она unsound, чисто чтобы банальные ошибки ловить) и есть ещё проект который в процессе с полноценной статической типизацией для Elixir. А, ну и есть Gleam, который уже со статической типизацией. Оп-па, ты и тут проебался и нихуя не знаешь.
Дальше про PubSub ты какую-то хуйню пишешь. На PubSub пишут не только в Elixir, есть ещё MQTT, есть всякие платные аналогичные сервисы от cloud-провайдеров типа AWS SNS и аналогов, и есть ещё дохуя других PubSub решений. Люди на MQTT-брокерах делают заводы на IoT платках, которые заменяют успешно заменяют заводы на которых работают как раз такие долбоёбы вроде тебя. И пока ты тут пиздишь что это 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 решения и гребут бабки лопатой. И даже здесь ты проебался.
В итоге, в каждой хуйне, которую ты тут высирал, ты был фактически не прав. Не то что бы это были какие-то открытые вопросы, и у нас было разное мнение, а это были тупо факты, которых ты не знал, и тупо кукарекал в моём тредике. Поэтому я и прошу тебя съебаться нахуй отсюда и не ебать тут адекватным людям мозги своими высерами
>>468061
Заорал нахуй с завода на пабсабе! Ебало инженера представили который ходит по цехам и пытается понять интерфейсы каждого устройства, потому что документация немного не в порядке.
Пиздец ты фантазёр-дегенерат, братишка.
Заорал нахуй с завода на пабсабе! Ебало инженера представили который ходит по цехам и пытается понять интерфейсы каждого устройства, потому что документация немного не в порядке.
Пиздец ты фантазёр-дегенерат, братишка.
>>468061
Алсо, ты не понимаешь что пабсаб вообще не предназначен для заводов, потому что нужна надёжная доставка сообщений и логирования, а это ломает всю парадигму пабсаба - низкую связанность. Это классически архитектурный проёб от долбоёба на архитекторе. Видимо ты даже не писал никогда на пабсабе, если этого не понимаешь.
Не буду утруждать тебя размышлениями, а то ещё умнее станешь.
Алсо, ты не понимаешь что пабсаб вообще не предназначен для заводов, потому что нужна надёжная доставка сообщений и логирования, а это ломает всю парадигму пабсаба - низкую связанность. Это классически архитектурный проёб от долбоёба на архитекторе. Видимо ты даже не писал никогда на пабсабе, если этого не понимаешь.
Не буду утруждать тебя размышлениями, а то ещё умнее станешь.
>>468064
Пиздец как мимо ты пишешь, родной. Почитай про MQTT и основные места его применения. Доставка бывает достоверной, а бывает надо собрать данные со 100500 различных датчиков, и вот тут и используют MQTT. Опять же, у тебя очко шире чем кругозор. Ты меня просто заебал своей поверхностной хуйнёй
Пиздец как мимо ты пишешь, родной. Почитай про MQTT и основные места его применения. Доставка бывает достоверной, а бывает надо собрать данные со 100500 различных датчиков, и вот тут и используют MQTT. Опять же, у тебя очко шире чем кругозор. Ты меня просто заебал своей поверхностной хуйнёй
>>468068
Ладно, так и быть, раскрою немного секретов необразованцу-фантазёру. Backpressure. Думай теперь.
>MQTT
>Доставка бывает достоверной
Ладно, так и быть, раскрою немного секретов необразованцу-фантазёру. Backpressure. Думай теперь.
>>468206
Что backpressure? Ты понимаешь что такое датчик? Это микромаленькая одноплатная хуйня на 50кб памяти, которая может послать сообщение по UDP, но не может сохранить в памяти больше чем 2 сообщения. Какой нахуй backpressure в IoT
Поэтому и используют MQTT: если сабскрайбер не хочет получать сообщение, он его просто скипает, потому что других вариантов у него особо и нет. И, если что, у MQTT есть 3 уровня разных гарантий доставки (от клиента брокеру).
Опять же, ты проёбываешься буквально в каждой хуйне, которую пишешь.
Что backpressure? Ты понимаешь что такое датчик? Это микромаленькая одноплатная хуйня на 50кб памяти, которая может послать сообщение по UDP, но не может сохранить в памяти больше чем 2 сообщения. Какой нахуй backpressure в IoT
Поэтому и используют MQTT: если сабскрайбер не хочет получать сообщение, он его просто скипает, потому что других вариантов у него особо и нет. И, если что, у MQTT есть 3 уровня разных гарантий доставки (от клиента брокеру).
Опять же, ты проёбываешься буквально в каждой хуйне, которую пишешь.
512x512>>466822
В голосину с этой саксес стори
https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users
>Хочешь саксесс стори на Elixir? Дискорд.
В голосину с этой саксес стори
https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users
>>468452
Discord переписывают два небольших алгоритма на Rust чисто для работы с мутабельной shared-memory и из-за этого все остальные 99.9% кода перестают быть Elixir-ом?
Ты ахуеешь, но рантайм языка и многие встроенные модули (типа crypto) написаны на C. Как и, например, Nx это один большой NIF. Получается нет ни одной программы чисто на Elixir?
Discord переписывают два небольших алгоритма на Rust чисто для работы с мутабельной shared-memory и из-за этого все остальные 99.9% кода перестают быть Elixir-ом?
Ты ахуеешь, но рантайм языка и многие встроенные модули (типа crypto) написаны на C. Как и, например, Nx это один большой NIF. Получается нет ни одной программы чисто на Elixir?
>>468461
По факту история повторяется с эрлангом. Элексир используют как клей для модулей на других языках
По факту история повторяется с эрлангом. Элексир используют как клей для модулей на других языках
>>468485
Что значит клей? Elixir более высокоуровневый язык чем C или Rust, конечно. Я бы даже сказал что он более высокоуровневый чем Java, C# и даже Python. Но даже эти же C#, Java, Python очень часто используют нативный код в том или ином виде (как минимум openssl). Но это не значит что эти языки это клей для C, потому что большая часть кода и логики там всё равно на высокоуровневом языке.
В случае с дискордом, там Rust-а очень мало. Если Elixir это клей для Rust, то хули у них клея в сотни раз больше чем Rust-а. По твоей логике можно сказать что C в юзерспейсе это клей для системных вызовов, а операционная система это клей для драйверов, а драйвера это клей для ассемблера. Кароче, нихуя нормального по твоей логике не получается
Что значит клей? Elixir более высокоуровневый язык чем C или Rust, конечно. Я бы даже сказал что он более высокоуровневый чем Java, C# и даже Python. Но даже эти же C#, Java, Python очень часто используют нативный код в том или ином виде (как минимум openssl). Но это не значит что эти языки это клей для C, потому что большая часть кода и логики там всё равно на высокоуровневом языке.
В случае с дискордом, там Rust-а очень мало. Если Elixir это клей для Rust, то хули у них клея в сотни раз больше чем Rust-а. По твоей логике можно сказать что C в юзерспейсе это клей для системных вызовов, а операционная система это клей для драйверов, а драйвера это клей для ассемблера. Кароче, нихуя нормального по твоей логике не получается
>>468461
Там переписали 2 ключевых для перформанса участка. Потому что вся эта концепция с отсутствием разделяемой памяти, работает на узком класс задач типа телекома. А в большинстве обычных задач разделяемая память нужна. Тебе уже правильно сказали, в этой задаче эликсир просто клей. При желании они могли бы питон использовать для этого.
>Discord переписывают два небольших алгоритма на Rust чисто для работы с мутабельной shared-memory и из-за этого все остальные 99.9% кода перестают быть Elixir-ом?
Там переписали 2 ключевых для перформанса участка. Потому что вся эта концепция с отсутствием разделяемой памяти, работает на узком класс задач типа телекома. А в большинстве обычных задач разделяемая память нужна. Тебе уже правильно сказали, в этой задаче эликсир просто клей. При желании они могли бы питон использовать для этого.
>>468553
Родной, ты вообще статью прочитал? Твои высеры никак к аргументу что 99.9% бэка у них на Elixir не относятся и ему не противоречат.
Переписали два алгоритма на раст и ускорили свою систему. И что дальше-то? О чём это говорит? О том что Rust компилируется в zero-runtime натив, а у Elixir есть рантайм? Нихуя себе, вот это ты мне глаза открыл ебать.
А дальше-то что? Какой вывод? Что Elixir клей? Ну, ебать, если систему где весь код на Elixir кроме 300 строк на Rust, ты классифицируешь как "Rust — ядро, а Elixir — клей", то о чём с тобой вообще говорить-то нахуй. Если так, то я вообще удивлён как ты на клавиатуре тогда по кнопочкам попадаешь
Родной, ты вообще статью прочитал? Твои высеры никак к аргументу что 99.9% бэка у них на Elixir не относятся и ему не противоречат.
Переписали два алгоритма на раст и ускорили свою систему. И что дальше-то? О чём это говорит? О том что Rust компилируется в zero-runtime натив, а у Elixir есть рантайм? Нихуя себе, вот это ты мне глаза открыл ебать.
А дальше-то что? Какой вывод? Что Elixir клей? Ну, ебать, если систему где весь код на Elixir кроме 300 строк на Rust, ты классифицируешь как "Rust — ядро, а Elixir — клей", то о чём с тобой вообще говорить-то нахуй. Если так, то я вообще удивлён как ты на клавиатуре тогда по кнопочкам попадаешь
>>468611
Мудило! 99% это твоя больная фантазия, они пишут про
У них вообще зоопарк языков https://github.com/orgs/discord/repositories?type=all от С++ до Скалы.
Дебил, ты бы прочел о чем там вообще пишут:
Там личерали речь идёт о приложении которое обслуживает список пользователей в канале. Понятно, что структура которая хранит и управляет этим списком, это главное, что влияет на перформанс приложения, о чем собственно статья и говорит.
Эликсир нишевый продукт, который мало кому уперсы.
Дебил удивляется, что с его тупым мнением не согласны. Только на двачах, без регистрации и СМС.
>Родной, ты вообще статью прочитал? Твои высеры никак к аргументу что 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
Там личерали речь идёт о приложении которое обслуживает список пользователей в канале. Понятно, что структура которая хранит и управляет этим списком, это главное, что влияет на перформанс приложения, о чем собственно статья и говорит.
>А дальше-то что? Какой вывод?
Эликсир нишевый продукт, который мало кому уперсы.
>о чём с тобой вообще говорить-то нахуй. Если так, то я вообще удивлён как ты на клавиатуре тогда по кнопочкам попадаешь
Дебил удивляется, что с его тупым мнением не согласны. Только на двачах, без регистрации и СМС.
>>468553
После такого градуса хуйни троль обычно отправляет в игнор. То есть тут настолько лютейшая хуета и некомпетентность в каждом предложении, что я даже не ебу, о чем разговор продолжается.
Ладно если человек мало понимает в предмете и старается понять, но этот ведь даже не старается.
Вы просто засираете тред своим спором.
>Там переписали 2 ключевых для перформанса участка. Потому что вся эта концепция с отсутствием разделяемой памяти, работает на узком класс задач типа телекома. А в большинстве обычных задач разделяемая память нужна. Тебе уже правильно сказали, в этой задаче эликсир просто клей. При желании они могли бы питон использовать для этого.
После такого градуса хуйни троль обычно отправляет в игнор. То есть тут настолько лютейшая хуета и некомпетентность в каждом предложении, что я даже не ебу, о чем разговор продолжается.
Ладно если человек мало понимает в предмете и старается понять, но этот ведь даже не старается.
Вы просто засираете тред своим спором.
>>468722
Удваиваю, мне в целом похуй на мнение этого клоуна. Мне важно только чтобы у поверхностно читающих этот тредик не сложилось неправильное впечатление. Мы-то с тобой знаем детали языка и его использования и поэтому понимаем почему этот клоун не прав, а анон, который просто зайдёт про язычок почитать, деталей не знает и может реально клоуну поверить.
>>468698
Сразу понятно что ты дальше своей жирной залупы нихуя не видишь. Большинство репок там это форки либ для фронтендов, для клиентских приложений.
Не приложении, а структуре: OrderedSet, который списочек юзеров просто, и всё. Нихуя больше. Чисто структурка которая показывает всех юзеров в гильдии. Основной функционал приложения (войс, чаты) написаны на Elixir (не считая кодеков, которые как либы на C++)
Так тебя никто не заставляет им пользоваться. Не обижайся, но всем здесь на тебя абсолютно похуй. Да-да. Можешь пожаловаться маме, а потом рассказать ей ещё пару интересных фактов про языки программирования, которые ты сам придумал. Но реальность от этого не изменится. А состоит она в том, что Discord, Remote, WhatNot и кучи других компаний написали свои бэки на Elixir и теперь гребут ахуенные бабки, пока ты здесь с пеной у рта доказываешь что на Elixir нихуя нельзя нормально написать.
> Вы просто засираете тред своим спором.
Удваиваю, мне в целом похуй на мнение этого клоуна. Мне важно только чтобы у поверхностно читающих этот тредик не сложилось неправильное впечатление. Мы-то с тобой знаем детали языка и его использования и поэтому понимаем почему этот клоун не прав, а анон, который просто зайдёт про язычок почитать, деталей не знает и может реально клоуну поверить.
>>468698
> зоопарк языков
> 99% это твоя больная фантазия, они пишут про
Сразу понятно что ты дальше своей жирной залупы нихуя не видишь. Большинство репок там это форки либ для фронтендов, для клиентских приложений.
> приложении которое обслуживает список пользователей в канале
Не приложении, а структуре: OrderedSet, который списочек юзеров просто, и всё. Нихуя больше. Чисто структурка которая показывает всех юзеров в гильдии. Основной функционал приложения (войс, чаты) написаны на Elixir (не считая кодеков, которые как либы на C++)
> Эликсир нишевый продукт, который мало кому уперсы.
Так тебя никто не заставляет им пользоваться. Не обижайся, но всем здесь на тебя абсолютно похуй. Да-да. Можешь пожаловаться маме, а потом рассказать ей ещё пару интересных фактов про языки программирования, которые ты сам придумал. Но реальность от этого не изменится. А состоит она в том, что Discord, Remote, WhatNot и кучи других компаний написали свои бэки на Elixir и теперь гребут ахуенные бабки, пока ты здесь с пеной у рта доказываешь что на Elixir нихуя нельзя нормально написать.
>>468730
Ты какой-то максимально упоротый фанатик. Вангую в тебе студента, который прод не нюхал. Что толку обсуждать язык, на который ноль вакансий? Что толку тебе с того дискорда? Ты там не работаешь и никогда работать не будешь, ты не в США живешь, наркоман.
Ты какой-то максимально упоротый фанатик. Вангую в тебе студента, который прод не нюхал. Что толку обсуждать язык, на который ноль вакансий? Что толку тебе с того дискорда? Ты там не работаешь и никогда работать не будешь, ты не в США живешь, наркоман.
>>468730
Честно говоря, я плохо понимаю, почему случайному прохожему может по какой-то причине понравиться эрланг. Я помню, как очень много лет назад поинтересовался, что это за эрланг, на котором 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% ебли заключается в смене схемы постгри? Какая разница в том, какая доля системы сумела восстановиться, если по итогу система в целом неработоспособна, потому что постгря не включена в деревья супервизии?
Как вы понимаете, я уже задавал подобные вопросы нейросетке — она только всплакнула, сказала что-то про "жизнь — страдание, мы все умрём", и ушла в закат.
>>468730
Честно говоря, я плохо понимаю, почему случайному прохожему может по какой-то причине понравиться эрланг. Я помню, как очень много лет назад поинтересовался, что это за эрланг, на котором 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% ебли заключается в смене схемы постгри? Какая разница в том, какая доля системы сумела восстановиться, если по итогу система в целом неработоспособна, потому что постгря не включена в деревья супервизии?
Как вы понимаете, я уже задавал подобные вопросы нейросетке — она только всплакнула, сказала что-то про "жизнь — страдание, мы все умрём", и ушла в закат.
>>469825
Эрланг интересен своей концепцией, на этом все. Писать код на акторах и шине событий пиздец как неудобно, вообще ничего не понятно. Вон в голанге сделали, как в эрланге, добавили ранге по каналу, никто этим не пользуется. Классический императивный код с мьютексами легко читать и понимать, в отличие от.
Эрланг интересен своей концепцией, на этом все. Писать код на акторах и шине событий пиздец как неудобно, вообще ничего не понятно. Вон в голанге сделали, как в эрланге, добавили ранге по каналу, никто этим не пользуется. Классический императивный код с мьютексами легко читать и понимать, в отличие от.
>>469826
И что ты предлагаешь? Делать Discord на базе одного сервера с node.js? Или у тебя есть какие-то волшебные мьютексы, которые живут сразу на нескольких серверах?
>Классический императивный код с мьютексами легко читать и понимать, в отличие от.
И что ты предлагаешь? Делать Discord на базе одного сервера с node.js? Или у тебя есть какие-то волшебные мьютексы, которые живут сразу на нескольких серверах?
>>469833
Я точно понимаю, что такое мьютекс. Ты будешь вопросом на вопрос отвечать?
>Ты точно понимаешь, что такое мьютекс?
Я точно понимаю, что такое мьютекс. Ты будешь вопросом на вопрос отвечать?
>>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 в этом плане тупо выгоднее и проще.
> проблема разделяемого состояния не решена
Это я не совсем понял. В 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 в этом плане тупо выгоднее и проще.
>>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 в этом плане тупо выгоднее и проще.
> проблема разделяемого состояния не решена
Это я не совсем понял. В 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
На словах ты Лев Толстой, а на деле на эликсир нет вакансий. Ты напоминаешь хаскелистов с их охуительными историями про лучший язык.
На словах ты Лев Толстой, а на деле на эликсир нет вакансий. Ты напоминаешь хаскелистов с их охуительными историями про лучший язык.
>>470483
Если ты про РФ, то да, сейчас Elixir-а практически нет, раньше было больше, но что-то случилось. Был ещё довольно активный рыночек вакансий в Украине, но тоже что-то случилось с ним.
В ЕС и США есть нормальное количество ваканский, в основном удалённая работа, и их в целом достаточно. То есть ваканский меньше чем на Python и Java, например, но и разработчиков не очень много, поэтому я думаю в целом отношение соискатели/вакансии такое же как и в других языках, и найти работу не сложнее чем на них.
Если ты не знаешь английский и не согласен работать удалённо, то я плохо понимаю нахуя ты в айти вообще забыл
Если ты про РФ, то да, сейчас Elixir-а практически нет, раньше было больше, но что-то случилось. Был ещё довольно активный рыночек вакансий в Украине, но тоже что-то случилось с ним.
В ЕС и США есть нормальное количество ваканский, в основном удалённая работа, и их в целом достаточно. То есть ваканский меньше чем на Python и Java, например, но и разработчиков не очень много, поэтому я думаю в целом отношение соискатели/вакансии такое же как и в других языках, и найти работу не сложнее чем на них.
Если ты не знаешь английский и не согласен работать удалённо, то я плохо понимаю нахуя ты в айти вообще забыл
>>470501
Подскажи тогда книги/курсы для вката новичку, пожалуйста. Заебался быть SQL аналитиком, а в пиздон идти желания ещё меньше. Английский средний, могу общаться на бытовом уровне.
Подскажи тогда книги/курсы для вката новичку, пожалуйста. Заебался быть SQL аналитиком, а в пиздон идти желания ещё меньше. Английский средний, могу общаться на бытовом уровне.
>>470501
Без ворк пермита идешь нахуй.
Без американского паспорта идешь нахуй.
Что и требовалось доказать.
>ЕС
Без ворк пермита идешь нахуй.
>США
Без американского паспорта идешь нахуй.
Что и требовалось доказать.
>>470650
Я понимаю почему ты ошибаешься. На уроках обществознания тебе пока что не рассказали про то что такое ИП, как его открыть в соседней стране по интернету и как октрыть валютный счёт для своего бизнеса. Отношусь к тебе с пониманием, ты просто не знал про это, ведь в пятом классе про это ещё пока не рассказали.
> Без ворк пермита идешь нахуй.
> Без американского паспорта идешь нахуй.
Я понимаю почему ты ошибаешься. На уроках обществознания тебе пока что не рассказали про то что такое ИП, как его открыть в соседней стране по интернету и как октрыть валютный счёт для своего бизнеса. Отношусь к тебе с пониманием, ты просто не знал про это, ведь в пятом классе про это ещё пока не рассказали.
>>470619
Есть курс от Алексея Матюшкина, я слышал про него хорошие отзывы, но слышал и плохие (не о курсе, а лично об Алексее), так что решай сам.
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 это объективный кал
Есть курс от Алексея Матюшкина, я слышал про него хорошие отзывы, но слышал и плохие (не о курсе, а лично об Алексее), так что решай сам.
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 это объективный кал
>>470733
Проиграл в голос с этого дурачка. Еще раз, медленно, специально для тупых пориджей: без ворк пермита никому ты нахуй там не нуженю Литерали. Свое ИП можешь засунуть в свою тугую задницу. Даже сербы-братушки требуют перекат в течение месяца, всякие бриташки и голашки твое резюме вообще не откроют.
Проиграл в голос с этого дурачка. Еще раз, медленно, специально для тупых пориджей: без ворк пермита никому ты нахуй там не нуженю Литерали. Свое ИП можешь засунуть в свою тугую задницу. Даже сербы-братушки требуют перекат в течение месяца, всякие бриташки и голашки твое резюме вообще не откроют.
>>470998
Я мимо проходил. Расскажи если не трудно что за ворк пермит, как его получить и насколько это тяжело при нынешней ситуации?
Я мимо проходил. Расскажи если не трудно что за ворк пермит, как его получить и насколько это тяжело при нынешней ситуации?
>>470998
>>471230
Не слушай этого долбоёба, он с самого начала треда пишет сюда какую-то выдуманную хуйню.
Про ворк пермит. То есть разрешение на работу. Оно нужно только если ты устраиваешься в иностранную компанию как сотрудник. Тебе тогда дают рабочую визу и ты можешь переехать в страну где у компании офис. В 2025 году так делают только бигтехи, а компании поменьше нанимают только контрактников, потому что для них это тупо сильно дешевле.
Чтобы стать контрактником, тебе нужно иметь открытый бизнес не в РФ и валютный счёт на который можно получать деньги. Всё это делается за один день в Грузии, Казахстане или Армении (я так делал). В Сербии тоже можно это сделать, но нужен месяц или около того. Для всего этого нужен загран. И ещё есть какие-то сервисы которые это удалённо делают, но я тут не подскажу конкретные.
Потом ты просто устраиваешься как на любую работу в ЕС, и просишь оформить тебя по b2b как контрактника, потом присылаешь им свидетельство о регистрации ИП, номер валютного счёта. Подписываешь контракт и, поздравляю, ты работаешь удалённо на фирму в ЕС. Раз месяц/две недели/неделю ты отправляешь фирме инвойс и они тебе по нему платят на валютный счёт.
Я работаю таким образом уже 5 лет где-то. Полёт нормальный.
>>471230
> Расскажи если не трудно что за ворк пермит, как его получить и насколько это тяжело при нынешней ситуации?
Не слушай этого долбоёба, он с самого начала треда пишет сюда какую-то выдуманную хуйню.
Про ворк пермит. То есть разрешение на работу. Оно нужно только если ты устраиваешься в иностранную компанию как сотрудник. Тебе тогда дают рабочую визу и ты можешь переехать в страну где у компании офис. В 2025 году так делают только бигтехи, а компании поменьше нанимают только контрактников, потому что для них это тупо сильно дешевле.
Чтобы стать контрактником, тебе нужно иметь открытый бизнес не в РФ и валютный счёт на который можно получать деньги. Всё это делается за один день в Грузии, Казахстане или Армении (я так делал). В Сербии тоже можно это сделать, но нужен месяц или около того. Для всего этого нужен загран. И ещё есть какие-то сервисы которые это удалённо делают, но я тут не подскажу конкретные.
Потом ты просто устраиваешься как на любую работу в ЕС, и просишь оформить тебя по b2b как контрактника, потом присылаешь им свидетельство о регистрации ИП, номер валютного счёта. Подписываешь контракт и, поздравляю, ты работаешь удалённо на фирму в ЕС. Раз месяц/две недели/неделю ты отправляешь фирме инвойс и они тебе по нему платят на валютный счёт.
Я работаю таким образом уже 5 лет где-то. Полёт нормальный.
>>471284
Долбоеб тут только ты. Ты сравниваешь рынок пять лет назад и сейчас. Сейчас тебя никто не возьмет на B2B, литерали никто. Будут год искать, занесут кучу бабла агенствам, в итоге возьмут чурку с местным аусвайсом. Рынок труда пошел по пизде, пока ты сидел в своем манямирке, дебил блять.
Долбоеб тут только ты. Ты сравниваешь рынок пять лет назад и сейчас. Сейчас тебя никто не возьмет на B2B, литерали никто. Будут год искать, занесут кучу бабла агенствам, в итоге возьмут чурку с местным аусвайсом. Рынок труда пошел по пизде, пока ты сидел в своем манямирке, дебил блять.
>>471230
Найти работу с релокацией. Можешь попробовать прямо сейчас, открываешь линкедин и подаешься.
Найти работу с релокацией. Можешь попробовать прямо сейчас, открываешь линкедин и подаешься.
>>471367
Да-да, понял тебя, продолжай наблюдение. Нам очень интересно. Я пока ещё инвойсик отправлю.
>>471370
Я пробовал, но это сложнее чем удалёнку. Мне в компаниях открыто говорят, что релокация это просто куча бюрократической душки для них и они думают что им нужен юрист для этого (я-то знаю что это не так, но они почему-то так считают), и ещё им налогов больше платить и т.д. Поэтому на 10 вакансий с удалёнкой я нахожу лишь одну с релокейтом, и там на интервью на меня криво смотрят из-за паспорта. Кароче, после ковида всё стало удалённым, а после 2022 это ещё и сложнее стало конкретно для тех кто из РФ
Да-да, понял тебя, продолжай наблюдение. Нам очень интересно. Я пока ещё инвойсик отправлю.
>>471370
Я пробовал, но это сложнее чем удалёнку. Мне в компаниях открыто говорят, что релокация это просто куча бюрократической душки для них и они думают что им нужен юрист для этого (я-то знаю что это не так, но они почему-то так считают), и ещё им налогов больше платить и т.д. Поэтому на 10 вакансий с удалёнкой я нахожу лишь одну с релокейтом, и там на интервью на меня криво смотрят из-за паспорта. Кароче, после ковида всё стало удалённым, а после 2022 это ещё и сложнее стало конкретно для тех кто из РФ
>>470450
При всей адовой дроче на распределённость, уровень развития распределённых вычислений в индустрии очень грустный. То есть, готовые решения есть только для узких ниш, для других ниш решения нужно собирать из кирпичей из клея, а в третьих лепить почти с нуля.
Я застал ещё те времена, когда в постгре вообще не было встроенной потоковой репликации, репликацию делали на логическом уровне, повторяя SQL запросы на нескольких серверах, или же копируя WAL по SSH. Между прочим, Facebook до сих пор использует похожую модель (но давай лучше не будем про Facebook, потому что меня сейчас понесёт).
Такая организация логична, то есть, иерархия железо => машина из железа => сеть из машин. Индустрия уже очень давно делает вещь, которая ебанутая по своей сути: иммитирует работу примитивного железа при помощи машины, а когда не хватает всей машины — при помощи сети из машин. То есть, телега впереди лошади, жесткий диск из кластера машин, оперативная память из баз данных.
Да, это попытка упростить решение, свести сложную задачу к набору известных простых задач, но эти же "простые задачи" создают настолько много проблем, что нужен целый гугл или яндекс для эффективного их решения. Более того, ни гуглу, ни яндексу в хуй не упёрлось создание простого фреймворка организации сложных систем, потому что если завтра каждый васян создаст свою масштабируемую систему без AWS/GCP/Azure/Yandex Cloud, то все эти параши останутся без главного источника заработка. Я неоднократно наблюдал чудовищное переусложнение продуктов в таких корпорациях "потому что мы можем".
Erlang/BEAM уже частично пытались решить подобную задачу — это, как я указал, DETS, который организует локальное хранилище на одном узле, а координацию между узлами нужно писать ручками. Хочешь пиши шарды, хочешь — какую-нибудь иерархию. Другое дело, что какого-то готового фреймворка (по крайней мере публичного) для надёжной организации координации таких хранилищ нет.
Да ради бога, используй внешнюю БД. Другое дело, что вот для персистентности лога мне чо использовать в Elixir? Eventstore? Которое опять на той же постгре в качестве бэка работает. Неужели нет в мире других СУБД, кроме постгри?
Обычно микросервисные доходят до маразма и гоняют десяток разношерстных БД, хотя бы ту же постгрю нескольких версий, чтобы когда одна отъебнулась — остальные работают.
Не поверишь — ту же самую историю мне рассказывали не так давно, только про микросервисы. "Частичный отказ, незатронутые сервисы продолжают работать, бла-бла-бла...".
Из этих 99% (на самом деле порядка 60% в случае того же Discord, остальное выполняется в Kafka, Redis, PostgreSQL, etc) где-то половина выполняет клеевую функцию, то есть, адаптирует одну модель к другой, обрабатывает вебсокеты, доступ к БД, сериализацию. Довольно часто делают это неоправдано сложно, просто чтобы адаптироваться к стороннему сервису, разработанному не нами и не под наши задачи.
Справедливости ради, микросервиснутые нынче вообще ебанулись на отличненько и у них доля клея в коде может доходить до 90-95%, по сути они кроме парсинга и генерации JSON (или имянейм протокола) ничего не делают.
У гугля все сервисы по сути представляют собой огромный монолит в монорепе, где изменение API делается одним коммитом сразу в кучу сервисов, а само API сделано в виде синхронных вызовов на Stubby/protobuf. То есть, всё связывание сервисов происходит на этапе компиляции и связывается напрямую один сервис с другим, без посредников, без кафок и постгрей. Заметь, что сервисы написаны на разных языках программирования, но по итогу работают как единая система. Если какому-то сервису нужна персистентность — зачастую он единолично взаимодействует с БД, заключая в себе сложность работы со схемой.
Иронично, что уже есть опенсорсные аналоги внутренних инструментов гугла (Borg => Kubernetes, Stubby => gRPC), но почему-то микросервиснутые используют их IRL предельно через жопу, со всякими там Rabbit/Kafka на каждый чих без типизации/версионирования пересылаемых сообщений и без способов отладить проблемы с обработкой этих сообщений, когда продьюсер уже давно съебался, а консюмеры до сих пор не могут понять, откуда эти сообщения высрались и что с ними делать.
Мне не нужно его искать — я он и есть, лол.
>Погоди, а на каком языке можно написать сервер, который дёргает 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++).
Мне не нужно его искать — я он и есть, лол.
>>470450
При всей адовой дроче на распределённость, уровень развития распределённых вычислений в индустрии очень грустный. То есть, готовые решения есть только для узких ниш, для других ниш решения нужно собирать из кирпичей из клея, а в третьих лепить почти с нуля.
Я застал ещё те времена, когда в постгре вообще не было встроенной потоковой репликации, репликацию делали на логическом уровне, повторяя SQL запросы на нескольких серверах, или же копируя WAL по SSH. Между прочим, Facebook до сих пор использует похожую модель (но давай лучше не будем про Facebook, потому что меня сейчас понесёт).
Такая организация логична, то есть, иерархия железо => машина из железа => сеть из машин. Индустрия уже очень давно делает вещь, которая ебанутая по своей сути: иммитирует работу примитивного железа при помощи машины, а когда не хватает всей машины — при помощи сети из машин. То есть, телега впереди лошади, жесткий диск из кластера машин, оперативная память из баз данных.
Да, это попытка упростить решение, свести сложную задачу к набору известных простых задач, но эти же "простые задачи" создают настолько много проблем, что нужен целый гугл или яндекс для эффективного их решения. Более того, ни гуглу, ни яндексу в хуй не упёрлось создание простого фреймворка организации сложных систем, потому что если завтра каждый васян создаст свою масштабируемую систему без AWS/GCP/Azure/Yandex Cloud, то все эти параши останутся без главного источника заработка. Я неоднократно наблюдал чудовищное переусложнение продуктов в таких корпорациях "потому что мы можем".
Erlang/BEAM уже частично пытались решить подобную задачу — это, как я указал, DETS, который организует локальное хранилище на одном узле, а координацию между узлами нужно писать ручками. Хочешь пиши шарды, хочешь — какую-нибудь иерархию. Другое дело, что какого-то готового фреймворка (по крайней мере публичного) для надёжной организации координации таких хранилищ нет.
Да ради бога, используй внешнюю БД. Другое дело, что вот для персистентности лога мне чо использовать в Elixir? Eventstore? Которое опять на той же постгре в качестве бэка работает. Неужели нет в мире других СУБД, кроме постгри?
Обычно микросервисные доходят до маразма и гоняют десяток разношерстных БД, хотя бы ту же постгрю нескольких версий, чтобы когда одна отъебнулась — остальные работают.
Не поверишь — ту же самую историю мне рассказывали не так давно, только про микросервисы. "Частичный отказ, незатронутые сервисы продолжают работать, бла-бла-бла...".
Из этих 99% (на самом деле порядка 60% в случае того же Discord, остальное выполняется в Kafka, Redis, PostgreSQL, etc) где-то половина выполняет клеевую функцию, то есть, адаптирует одну модель к другой, обрабатывает вебсокеты, доступ к БД, сериализацию. Довольно часто делают это неоправдано сложно, просто чтобы адаптироваться к стороннему сервису, разработанному не нами и не под наши задачи.
Справедливости ради, микросервиснутые нынче вообще ебанулись на отличненько и у них доля клея в коде может доходить до 90-95%, по сути они кроме парсинга и генерации JSON (или имянейм протокола) ничего не делают.
У гугля все сервисы по сути представляют собой огромный монолит в монорепе, где изменение API делается одним коммитом сразу в кучу сервисов, а само API сделано в виде синхронных вызовов на Stubby/protobuf. То есть, всё связывание сервисов происходит на этапе компиляции и связывается напрямую один сервис с другим, без посредников, без кафок и постгрей. Заметь, что сервисы написаны на разных языках программирования, но по итогу работают как единая система. Если какому-то сервису нужна персистентность — зачастую он единолично взаимодействует с БД, заключая в себе сложность работы со схемой.
Иронично, что уже есть опенсорсные аналоги внутренних инструментов гугла (Borg => Kubernetes, Stubby => gRPC), но почему-то микросервиснутые используют их IRL предельно через жопу, со всякими там Rabbit/Kafka на каждый чих без типизации/версионирования пересылаемых сообщений и без способов отладить проблемы с обработкой этих сообщений, когда продьюсер уже давно съебался, а консюмеры до сих пор не могут понять, откуда эти сообщения высрались и что с ними делать.
Мне не нужно его искать — я он и есть, лол.
>Погоди, а на каком языке можно написать сервер, который дёргает 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++).
Мне не нужно его искать — я он и есть, лол.
>>471511
Кстати это полный кал, никому не советую его использовать. Запись туда не durable, не атомарна и ещё и можно проебать запись потому что оно пишется сначала в кэш
Какого лога? Если у тебя лог событий типа как в EventSourcing/CommandSourcing, то бери тот же тул/сервис что и на другом языке, лол. Ещё есть Commanded, который обёртка для постгри. Если у тебя лог как лог, то пиши туда, куда бы и на другом языке писал: хочешь в файл, хочешь в базу, да куда хочешь кароче.
Не понял к чему это. И остальные твои мысли тоже не особо с моим постом связал.
Вообще в целом твой пост какой-то как будто ты свою телегу какую-то пишешь и к моему посту она слабо относится, как и вообще к Elixir. Причём тут редисы, кафки, постгри и вся хуйня, какие ещё гуглы и фейсбуки...
> DETS
Кстати это полный кал, никому не советую его использовать. Запись туда не durable, не атомарна и ещё и можно проебать запись потому что оно пишется сначала в кэш
> Другое дело, что вот для персистентности лога мне чо использовать в Elixir?
Какого лога? Если у тебя лог событий типа как в EventSourcing/CommandSourcing, то бери тот же тул/сервис что и на другом языке, лол. Ещё есть Commanded, который обёртка для постгри. Если у тебя лог как лог, то пиши туда, куда бы и на другом языке писал: хочешь в файл, хочешь в базу, да куда хочешь кароче.
> То есть, всё связывание сервисов происходит на этапе компиляции и связывается напрямую один сервис с другим, без посредников, без кафок и постгрей
Не понял к чему это. И остальные твои мысли тоже не особо с моим постом связал.
Вообще в целом твой пост какой-то как будто ты свою телегу какую-то пишешь и к моему посту она слабо относится, как и вообще к Elixir. Причём тут редисы, кафки, постгри и вся хуйня, какие ещё гуглы и фейсбуки...
>>470735
Питон и жс объективный кал, да, для души пишу скрипты на руби, на эти языки пересаживаться просто больно. :(
>Лучше всего будет выучить немного Python/JavaScript, попердеть в стул 1-2 года на работе до того как станешь Middle
Питон и жс объективный кал, да, для души пишу скрипты на руби, на эти языки пересаживаться просто больно. :(
>>470450
На любом. Хоть на ноде пишешь, там же пишешь демон который стартуют монолит если он разъебался.
Всё это нахуй не нужно, если есть нормальная БД которая поддерживает ACID и несколько процессов. Сервер просто пишет в БД с нескольких процессов и всё. Всё, больше ничего не нужно. Без всяких шуток. Ни эликсир не нужен, ни кафка. Даже редис и прочие кэш-калы не нужны, потому что БД может постоянно в памяти висеть, ибо так работают современные ОС.
> Погоди, а на каком языке можно написать сервер, который дёргает Postgres, чтобы он оставался работоспособным когда Postgres отъебнётся?
На любом. Хоть на ноде пишешь, там же пишешь демон который стартуют монолит если он разъебался.
> Elixir это про то что у тебя есть очень простая система акторов, очень сильный многозадачный рантайм
> Если конкретнее, и с примерами, тебе на Elixir не нужны редисы,
Всё это нахуй не нужно, если есть нормальная БД которая поддерживает ACID и несколько процессов. Сервер просто пишет в БД с нескольких процессов и всё. Всё, больше ничего не нужно. Без всяких шуток. Ни эликсир не нужен, ни кафка. Даже редис и прочие кэш-калы не нужны, потому что БД может постоянно в памяти висеть, ибо так работают современные ОС.
>>472478
Кафка нужна, чтобы быстро-быстро собирать инфу с дохуилиона датчиков в реальном времени. Запись в кафку быстрее, чем в бд, и она умеет раскидывать нагрузку по серверам. Например, у тебя йоба завод, который надо мониторить 24 на 7. Или у тебя сервис типа яндекс пробки, надо собирать координаты с навигаторов и рассчитывать скорость движения. Еще кафку используют для внутренней диспетчеризации по шардам, когда наружу торчит одна ручка, а внутри запись идет на разные шарды, прозрачно для пользователя.
Редис - это тупо кеш. Из него читать быстрее, чем из бд.
Можно сделать систему чисто на одной бд, но тогда твой сервер просто выдержит меньше рпс. Другой вопрос: а будет ли у говносайта говнопиццы столько рпс, чтобы понадобилась кафка.
Кафка нужна, чтобы быстро-быстро собирать инфу с дохуилиона датчиков в реальном времени. Запись в кафку быстрее, чем в бд, и она умеет раскидывать нагрузку по серверам. Например, у тебя йоба завод, который надо мониторить 24 на 7. Или у тебя сервис типа яндекс пробки, надо собирать координаты с навигаторов и рассчитывать скорость движения. Еще кафку используют для внутренней диспетчеризации по шардам, когда наружу торчит одна ручка, а внутри запись идет на разные шарды, прозрачно для пользователя.
Редис - это тупо кеш. Из него читать быстрее, чем из бд.
Можно сделать систему чисто на одной бд, но тогда твой сервер просто выдержит меньше рпс. Другой вопрос: а будет ли у говносайта говнопиццы столько рпс, чтобы понадобилась кафка.
>>472550
И она может внезапно упасть. Если твоя задача проебать данные - можешь смело заниматься этим.
Вот тут да, можно через прокси, ибо проёб данных не страшен, а согласованность данных не особо важна.
Нет, так же как и из БД, если брать БД достаточно производительные - чтение даже быстрее чем в редисе.
CRDT, шарды и пакетная обработка решают эту проблему. Офк, всё зависит от того какая БД используется.
> собирать инфу с дохуилиона датчиков в реальном времени.
> Запись в кафку быстрее, чем в бд, и она
И она может внезапно упасть. Если твоя задача проебать данные - можешь смело заниматься этим.
> Или у тебя сервис типа яндекс пробки
Вот тут да, можно через прокси, ибо проёб данных не страшен, а согласованность данных не особо важна.
> Редис - это тупо кеш. Из него читать быстрее, чем из бд.
Нет, так же как и из БД, если брать БД достаточно производительные - чтение даже быстрее чем в редисе.
> Можно сделать систему чисто на одной бд, но тогда твой сервер просто выдержит меньше рпс.
CRDT, шарды и пакетная обработка решают эту проблему. Офк, всё зависит от того какая БД используется.
>>472578
О, ты вернулся в тредик, долбоёб. Я думал уже всё, забыл. Я уже почти соскучился. В любом случае, специально для тебя поясню: кафка персистентная, то есть она записывает на диск данные, когда их в неё посылают (посылка наебнётся, если на диск не запишется). А данные на диске остаются, даже если компьютер выключить из розетки. Ещё кафка эти данные реплицирует между мастерами, так что падение одного мастера ухудшит перформанс, но не наебнёт кластер. Откуда ты хуйню про проёб данных придумал, мне сложно представить.
А когда ты сам придумываешь факты, и ими разъебываешь в тредиках, ты, наверное, себя потом за сосочки трогаешь и думаешь: "Какой же умный, какой же я ахуенный", да? Откуда ты это взял? То что у баз есть кэш? Так этот кэш ограниченный и не по всем таблицам и всем ключам. И что за база? Например Postgres при апдейте данных в таблице не удаляет старые и их надо отдельно вакуумить, поэтому при частом апдейте по ключу перформанс ухудшается. Далее, кэш работает с TTL обычно, в базах нет встроенных TTL, это можно сделать ручками, но это будет кал. Далее, SQL базы ещё парсят запросы, строят планы (во время этого они иногда в рандомные места таблицы лезут) и т.д., тогда как Redis просто парсит строку "GET <KEY>" в TCP пакете и сразу лезет в дерево поиска.
> И она может внезапно упасть. Если твоя задача проебать данные - можешь смело заниматься этим.
О, ты вернулся в тредик, долбоёб. Я думал уже всё, забыл. Я уже почти соскучился. В любом случае, специально для тебя поясню: кафка персистентная, то есть она записывает на диск данные, когда их в неё посылают (посылка наебнётся, если на диск не запишется). А данные на диске остаются, даже если компьютер выключить из розетки. Ещё кафка эти данные реплицирует между мастерами, так что падение одного мастера ухудшит перформанс, но не наебнёт кластер. Откуда ты хуйню про проёб данных придумал, мне сложно представить.
> БД достаточно производительные - чтение даже быстрее чем в редисе.
А когда ты сам придумываешь факты, и ими разъебываешь в тредиках, ты, наверное, себя потом за сосочки трогаешь и думаешь: "Какой же умный, какой же я ахуенный", да? Откуда ты это взял? То что у баз есть кэш? Так этот кэш ограниченный и не по всем таблицам и всем ключам. И что за база? Например Postgres при апдейте данных в таблице не удаляет старые и их надо отдельно вакуумить, поэтому при частом апдейте по ключу перформанс ухудшается. Далее, кэш работает с TTL обычно, в базах нет встроенных TTL, это можно сделать ручками, но это будет кал. Далее, SQL базы ещё парсят запросы, строят планы (во время этого они иногда в рандомные места таблицы лезут) и т.д., тогда как Redis просто парсит строку "GET <KEY>" в TCP пакете и сразу лезет в дерево поиска.
>>472923
Тебе так нравится когда тебя обоссывают? Хорошо, сейчас опять обоссу, приготовься.
Конечно сложно, ты же даунёнок который не в курсе про технологии за которые ты кукарекаешь.
Смотри, внимательно. Кафка поддерижвает ACID? Нет? Данные проебались. Понимаю, тебе сложно такое вообразить, видимо ты никогда не работал, только на двачке пиздишь, лолд
Да. Как ты узнал? Мне нравится унижать и представлять как ты потными ручками стучишь по клавишам, пытаясь оспорить реальность.
Файловые системы так работают - помещают часть файла с диска в озу. Не знал? Конечно не знал, откуда тебе такое знать.
Вместо прямого запроса к БД у тебя куча прокладок, кафок, редисов которые один и тот же запрос пересылают друг-другу. Какое же ты говноедище, боже. И часто у вас так в ерланг-манямирке происходит?
> О, ты вернулся в тредик, долбоёб. Я думал уже всё, забыл. Я уже почти соскучился.
Тебе так нравится когда тебя обоссывают? Хорошо, сейчас опять обоссу, приготовься.
> Откуда ты хуйню про проёб данных придумал, мне сложно представить.
Конечно сложно, ты же даунёнок который не в курсе про технологии за которые ты кукарекаешь.
Смотри, внимательно. Кафка поддерижвает ACID? Нет? Данные проебались. Понимаю, тебе сложно такое вообразить, видимо ты никогда не работал, только на двачке пиздишь, лолд
> А когда ты сам придумываешь факты, и ими разъебываешь в тредиках, ты, наверное, себя потом за сосочки трогаешь и думаешь: "Какой же умный, какой же я ахуенный", да?
Да. Как ты узнал? Мне нравится унижать и представлять как ты потными ручками стучишь по клавишам, пытаясь оспорить реальность.
> Откуда ты это взял? То что у баз есть кэш? Так этот кэш ограниченный и не по всем таблицам и всем ключам.
Файловые системы так работают - помещают часть файла с диска в озу. Не знал? Конечно не знал, откуда тебе такое знать.
> Postgres
> SQL
> тогда как Redis просто парсит строку "GET <KEY>" в TCP пакете и сразу лезет в дерево поиска.
Вместо прямого запроса к БД у тебя куча прокладок, кафок, редисов которые один и тот же запрос пересылают друг-другу. Какое же ты говноедище, боже. И часто у вас так в ерланг-манямирке происходит?
>>473054
Какой нахуй ACID, долбоёб. ACID применим к мутабельным транзакциям, а кафка это просто лог, и операция "записать в конец лога" там Durable, то есть не проёбывается, даунище.
И что дальше? Дело даже не в диске, пусть у меня вообще всё в памяти, дело в том что индекс и сами страницы нужно ещё сериализовывать, тогда как в редисе данные просто лежать в дереве, которое состоит из прямых ссылок в память. И ещё редис не занимается парсингом SQL, построением плана, валидацией данных и прочим.
Какая жалкая попытка подменить тезис, пиздос. Мог бы получше постараться. Мы тут обсуждаем не то как надо архитектурно все эти решения использовать, а ту хуйню которую ты спизданул что "в бд чтение даже быстрее чем в редисе". И по этой хуйне у тебя тупо нет аргументов
> Смотри, внимательно. Кафка поддерижвает ACID?
Какой нахуй ACID, долбоёб. ACID применим к мутабельным транзакциям, а кафка это просто лог, и операция "записать в конец лога" там Durable, то есть не проёбывается, даунище.
> Файловые системы так работают - помещают часть файла с диска в озу. Не знал? Конечно не знал, откуда тебе такое знать.
И что дальше? Дело даже не в диске, пусть у меня вообще всё в памяти, дело в том что индекс и сами страницы нужно ещё сериализовывать, тогда как в редисе данные просто лежать в дереве, которое состоит из прямых ссылок в память. И ещё редис не занимается парсингом SQL, построением плана, валидацией данных и прочим.
> Вместо прямого запроса к БД у тебя куча прокладок, кафок, редисов которые один и тот же запрос пересылают
Какая жалкая попытка подменить тезис, пиздос. Мог бы получше постараться. Мы тут обсуждаем не то как надо архитектурно все эти решения использовать, а ту хуйню которую ты спизданул что "в бд чтение даже быстрее чем в редисе". И по этой хуйне у тебя тупо нет аргументов
>>473223
Об этом и речь, даунёнок, ты не можешь зафиксировать данные в простом логе. Сообщения могут дублироваться, проёбываться, да что угодно может случиться.
И то что производительность ОС + нормальной бд лучше редиса кафки и той шизофрении которую тебе в мозг говноеды заложили.
Всё в порядке, в нормальных БД это такие же ссылки в память. Просто ты говна поел с редисом, кафкой и скулем, вот и не знаешь нормальных технологий.
Зачем тут аргументы если это эмпирический факт?
> Какой нахуй ACID, долбоёб. ACID применим к мутабельным транзакциям, а кафка это просто лог, и операция "записать в конец лога" там Durable, то есть не проёбывается, даунище.
Об этом и речь, даунёнок, ты не можешь зафиксировать данные в простом логе. Сообщения могут дублироваться, проёбываться, да что угодно может случиться.
> И что дальше?
И то что производительность ОС + нормальной бд лучше редиса кафки и той шизофрении которую тебе в мозг говноеды заложили.
> Дело даже не в диске, пусть у меня вообще всё в памяти, дело в том что индекс и сами страницы нужно ещё сериализовывать, тогда как в редисе данные просто лежать в дереве, которое состоит из прямых ссылок в память.
Всё в порядке, в нормальных БД это такие же ссылки в память. Просто ты говна поел с редисом, кафкой и скулем, вот и не знаешь нормальных технологий.
> Мы тут обсуждаем не то как надо архитектурно все эти решения использовать, а ту хуйню которую ты спизданул что "в бд чтение даже быстрее чем в редисе". И по этой хуйне у тебя тупо нет аргументов
Зачем тут аргументы если это эмпирический факт?
>>473677
Что ты вообще несёшь? Что значит "зафиксировать"? Я дёргаю апи метод append и если он завершился без ошибки, то эвент записался в лог. С этого момента он не проёбывается, потому что лежит на диске. Если я его дёрну ещё раз, то запись не дублируется, потому что есть ключ индемпотентности у сообщения. Какой же ты узколобый дебил, ей богу
Так ты это запруфай, еблан. Покажи бенчмарк или что-то такое. Но ты не покажешь, потому что если ты сделаешь бенчмарк, то ты увидишь что чтение из Redis по ключу быстрее чем из Postgres (даже если тот запущен в tmpfs)
Открываем статью где сравнивают перформанс редиса и постгри на чтение и запись по ключу и смотрим что постгрес сосёт: https://medium.com/redis-with-raphael-de-lio/can-postgres-replace-redis-as-a-cache-f6cba13386dc
Вот ещё один бенчмарк: https://archive.is/pQSnO
Кароче, иди нахуй, добоёбище. Обратно в питонотред или откуда ты там вылез
> Об этом и речь, даунёнок, ты не можешь зафиксировать данные в простом логе. Сообщения могут дублироваться, проёбываться, да что угодно может случиться.
Что ты вообще несёшь? Что значит "зафиксировать"? Я дёргаю апи метод append и если он завершился без ошибки, то эвент записался в лог. С этого момента он не проёбывается, потому что лежит на диске. Если я его дёрну ещё раз, то запись не дублируется, потому что есть ключ индемпотентности у сообщения. Какой же ты узколобый дебил, ей богу
> И то что производительность ОС + нормальной бд лучше редиса кафки и той шизофрении которую тебе в мозг говноеды заложили.
Так ты это запруфай, еблан. Покажи бенчмарк или что-то такое. Но ты не покажешь, потому что если ты сделаешь бенчмарк, то ты увидишь что чтение из Redis по ключу быстрее чем из Postgres (даже если тот запущен в tmpfs)
> эмпирический факт
Открываем статью где сравнивают перформанс редиса и постгри на чтение и запись по ключу и смотрим что постгрес сосёт: https://medium.com/redis-with-raphael-de-lio/can-postgres-replace-redis-as-a-cache-f6cba13386dc
Вот ещё один бенчмарк: https://archive.is/pQSnO
Кароче, иди нахуй, добоёбище. Обратно в питонотред или откуда ты там вылез
>>473677
Скажи честно: ты идиот? Или ты мазохист и любишь, когда тебя виртуально обоссывают?
Скажи честно: ты идиот? Или ты мазохист и любишь, когда тебя виртуально обоссывают?
>>473859
Пиздец манямирок у долбоёба. И это он пишет в элексиротреде! То что что-то завершилось не значит что данные не проебались, ты понимаешь это? Хотя ладно, очевидно что ты нихуя не понимаешь.
Буквально на любом этапе передачи сообщения может возникнуть сбой. Т.к. там есть кафка которая может менять лидера и проебывать лог - клиент поймает таймаут, отправит сообщение ещё раз и что ты там не фантазируй будет дублирование. И это ещё самый простой сценарий, который можно отловить и ограничить, в реальности всё будет куда хуже.
У тебя несколько сервисов которые не имеют прямой согласованности между собой, всё через пизду твоей мёртвой мамаши организовано, ты осознаёшь это? Гарантии на стороне кафки не равны гарантии стороне БД, а значит сообщения будут проёбываться.
Нахуй мне палить говноедам годноту. Страдай и жри говно.
Нормальная бд это не постгрес, говноедище.
Конечно сосёт, ведь это технологии даунов. И не забывай даунёнок, ты сначала должен данные отправить в свою говнобд, потом закэшировать запрос в редисе, отправить в кафку которая распределит по репликам, ору нах! В то время как я записываю данные на диск быстрее чем постгресс раза в три, читаю данные быстрее чем редис в два раза и в 20 раз быстрее чем постгресс, а клиенты пишут и читают напрямую в реплики, без всяких кафок, данные проебаться не могут в принципе.
Короче ты поспорил сам с собой. Ещё бы, ведь спорить с реальность тебе сложно, в ней ты всеми обоссаный дерьмоед с архитектурой которая создана для потери данных.
>>473899
Вот это защитная реакция пошла, лол
> Что ты вообще несёшь? Что значит "зафиксировать"? Я дёргаю апи метод append и если он завершился без ошибки, то эвент записался в лог.
Пиздец манямирок у долбоёба. И это он пишет в элексиротреде! То что что-то завершилось не значит что данные не проебались, ты понимаешь это? Хотя ладно, очевидно что ты нихуя не понимаешь.
> Если я его дёрну ещё раз, то запись не дублируется, потому что есть ключ индемпотентности у сообщения.
Буквально на любом этапе передачи сообщения может возникнуть сбой. Т.к. там есть кафка которая может менять лидера и проебывать лог - клиент поймает таймаут, отправит сообщение ещё раз и что ты там не фантазируй будет дублирование. И это ещё самый простой сценарий, который можно отловить и ограничить, в реальности всё будет куда хуже.
У тебя несколько сервисов которые не имеют прямой согласованности между собой, всё через пизду твоей мёртвой мамаши организовано, ты осознаёшь это? Гарантии на стороне кафки не равны гарантии стороне БД, а значит сообщения будут проёбываться.
> Так ты это запруфай, еблан. Покажи бенчмарк или что-то такое.
Нахуй мне палить говноедам годноту. Страдай и жри говно.
> Но ты не покажешь, потому что если ты сделаешь бенчмарк, то ты увидишь что чтение из Redis по ключу быстрее чем из Postgres (даже если тот запущен в tmpfs)
Нормальная бд это не постгрес, говноедище.
> Открываем статью где сравнивают перформанс редиса и постгри на чтение и запись по ключу и смотрим что постгрес сосёт:
Конечно сосёт, ведь это технологии даунов. И не забывай даунёнок, ты сначала должен данные отправить в свою говнобд, потом закэшировать запрос в редисе, отправить в кафку которая распределит по репликам, ору нах! В то время как я записываю данные на диск быстрее чем постгресс раза в три, читаю данные быстрее чем редис в два раза и в 20 раз быстрее чем постгресс, а клиенты пишут и читают напрямую в реплики, без всяких кафок, данные проебаться не могут в принципе.
> Кароче, иди нахуй, добоёбище. Обратно в питонотред или откуда ты там вылез
Короче ты поспорил сам с собой. Ещё бы, ведь спорить с реальность тебе сложно, в ней ты всеми обоссаный дерьмоед с архитектурой которая создана для потери данных.
>>473899
> нееет, это не я обоссаная чмоня которая рассказывает про говноедский стек, это ты!11
Вот это защитная реакция пошла, лол
>>473859
Пиздец манямирок у долбоёба. И это он пишет в элексиротреде! То что что-то завершилось не значит что данные не проебались, ты понимаешь это? Хотя ладно, очевидно что ты нихуя не понимаешь.
Буквально на любом этапе передачи сообщения может возникнуть сбой. Т.к. там есть кафка которая может менять лидера и проебывать лог - клиент поймает таймаут, отправит сообщение ещё раз и что ты там не фантазируй будет дублирование. И это ещё самый простой сценарий, который можно отловить и ограничить, в реальности всё будет куда хуже.
У тебя несколько сервисов которые не имеют прямой согласованности между собой, всё через пизду твоей мёртвой мамаши организовано, ты осознаёшь это? Гарантии на стороне кафки не равны гарантии стороне БД, а значит сообщения будут проёбываться.
Нахуй мне палить говноедам годноту. Страдай и жри говно.
Нормальная бд это не постгрес, говноедище.
Конечно сосёт, ведь это технологии даунов. И не забывай даунёнок, ты сначала должен данные отправить в свою говнобд, потом закэшировать запрос в редисе, отправить в кафку которая распределит по репликам, ору нах! В то время как я записываю данные на диск быстрее чем постгресс раза в три, читаю данные быстрее чем редис в два раза и в 20 раз быстрее чем постгресс, а клиенты пишут и читают напрямую в реплики, без всяких кафок, данные проебаться не могут в принципе.
Короче ты поспорил сам с собой. Ещё бы, ведь спорить с реальность тебе сложно, в ней ты всеми обоссаный дерьмоед с архитектурой которая создана для потери данных.
>>473899
Вот это защитная реакция пошла, лол
> Что ты вообще несёшь? Что значит "зафиксировать"? Я дёргаю апи метод append и если он завершился без ошибки, то эвент записался в лог.
Пиздец манямирок у долбоёба. И это он пишет в элексиротреде! То что что-то завершилось не значит что данные не проебались, ты понимаешь это? Хотя ладно, очевидно что ты нихуя не понимаешь.
> Если я его дёрну ещё раз, то запись не дублируется, потому что есть ключ индемпотентности у сообщения.
Буквально на любом этапе передачи сообщения может возникнуть сбой. Т.к. там есть кафка которая может менять лидера и проебывать лог - клиент поймает таймаут, отправит сообщение ещё раз и что ты там не фантазируй будет дублирование. И это ещё самый простой сценарий, который можно отловить и ограничить, в реальности всё будет куда хуже.
У тебя несколько сервисов которые не имеют прямой согласованности между собой, всё через пизду твоей мёртвой мамаши организовано, ты осознаёшь это? Гарантии на стороне кафки не равны гарантии стороне БД, а значит сообщения будут проёбываться.
> Так ты это запруфай, еблан. Покажи бенчмарк или что-то такое.
Нахуй мне палить говноедам годноту. Страдай и жри говно.
> Но ты не покажешь, потому что если ты сделаешь бенчмарк, то ты увидишь что чтение из Redis по ключу быстрее чем из Postgres (даже если тот запущен в tmpfs)
Нормальная бд это не постгрес, говноедище.
> Открываем статью где сравнивают перформанс редиса и постгри на чтение и запись по ключу и смотрим что постгрес сосёт:
Конечно сосёт, ведь это технологии даунов. И не забывай даунёнок, ты сначала должен данные отправить в свою говнобд, потом закэшировать запрос в редисе, отправить в кафку которая распределит по репликам, ору нах! В то время как я записываю данные на диск быстрее чем постгресс раза в три, читаю данные быстрее чем редис в два раза и в 20 раз быстрее чем постгресс, а клиенты пишут и читают напрямую в реплики, без всяких кафок, данные проебаться не могут в принципе.
> Кароче, иди нахуй, добоёбище. Обратно в питонотред или откуда ты там вылез
Короче ты поспорил сам с собой. Ещё бы, ведь спорить с реальность тебе сложно, в ней ты всеми обоссаный дерьмоед с архитектурой которая создана для потери данных.
>>473899
> нееет, это не я обоссаная чмоня которая рассказывает про говноедский стек, это ты!11
Вот это защитная реакция пошла, лол
>>473944
Лол, он же реально шизик.
>ты сначала должен данные отправить в свою говнобд, потом закэшировать запрос в редисе, отправить в кафку которая распределит по репликам, ору нах! В то время как я записываю данные на диск быстрее чем постгресс раза в три, читаю данные быстрее чем редис в два раза и в 20 раз быстрее чем постгресс, а клиенты пишут и читают напрямую в реплики, без всяких кафок, данные проебаться не могут в принципе.
Лол, он же реально шизик.
>>473953
Сложно представить такие топовые технологии, отсталый каложуй?
Сложно представить такие топовые технологии, отсталый каложуй?
>>473944
Мне к этому нечего добавить, жаль тебя, я не понимаю нахуя ты в тред какую-то хуйню пишешь. Я уже начал думать что ты реально страдаешь чем-то вроде слабоумия или какого-то другого синдрома, где больные хуйню несут неконтроллируемо.
UPD: Бля, если ты скажешь Oracle, я обоссусь от смеха, дедуля
Блять ну вот как тебе объяснить, что я посылаю апи запрос, кафка пишет сообщение на диск и только после этого посылает ответ. Если я получил ответ, то сообщение на диске, ты это-то понимаешь той хуйнёй, что вот чуть-чуть выше дырочки на голове, куда ты свой кал кладёшь пожевать? Куда оно с диска проебётся?
Вот же дегенерат. Это к твоей ахуенной маня-БД применимо, а к кафке нет, потому что там есть ключ идемпотентности. Ты не знаешь про такую технологию, поэтому я поясню. Когда я посылаю сообщение на запись, я рядом с ним посылаю уникальный номер. Кафка этот номер тоже записывает на какое-то время, поэтому когда я ретрайну запись, я ретрайну её с этим же номером и кафка быстро проверит, дубликат это записи или нет.
Вот точно есть какое-то заболевание. Сначала сам спизданул какую-то хуйню, его поставили на место, ведь аргументов ноль. Поэтому он потом спизданул другую хуйню, уже за оппонента, и третьей хуйнёй успешно разъебал. В итоге весь тред в ахуе сидит с больного, который сам с собой срётся
> Написал хуйню, без пруфов и аргументов
> Нахуй мне палить говноедам годноту.
Мне к этому нечего добавить, жаль тебя, я не понимаю нахуя ты в тред какую-то хуйню пишешь. Я уже начал думать что ты реально страдаешь чем-то вроде слабоумия или какого-то другого синдрома, где больные хуйню несут неконтроллируемо.
UPD: Бля, если ты скажешь Oracle, я обоссусь от смеха, дедуля
> То что что-то завершилось не значит что данные не проебались
Блять ну вот как тебе объяснить, что я посылаю апи запрос, кафка пишет сообщение на диск и только после этого посылает ответ. Если я получил ответ, то сообщение на диске, ты это-то понимаешь той хуйнёй, что вот чуть-чуть выше дырочки на голове, куда ты свой кал кладёшь пожевать? Куда оно с диска проебётся?
> клиент поймает таймаут, отправит сообщение ещё раз и что ты там не фантазируй будет дублирование
Вот же дегенерат. Это к твоей ахуенной маня-БД применимо, а к кафке нет, потому что там есть ключ идемпотентности. Ты не знаешь про такую технологию, поэтому я поясню. Когда я посылаю сообщение на запись, я рядом с ним посылаю уникальный номер. Кафка этот номер тоже записывает на какое-то время, поэтому когда я ретрайну запись, я ретрайну её с этим же номером и кафка быстро проверит, дубликат это записи или нет.
> ты сначала должен данные отправить в свою говнобд, потом закэшировать запрос в редисе, отправить в кафку которая распределит по репликам
Вот точно есть какое-то заболевание. Сначала сам спизданул какую-то хуйню, его поставили на место, ведь аргументов ноль. Поэтому он потом спизданул другую хуйню, уже за оппонента, и третьей хуйнёй успешно разъебал. В итоге весь тред в ахуе сидит с больного, который сам с собой срётся
>>474258
Неприятно, обоссанец? Конечно тебе неприятно, ведь вместо нормальных технологий ты переваренный кал хуячишь.
Хм, а ведь анон был прав, что ты студент который ни дня не работал, только фантазируешь в этом итт треде, лол
Что ты несешь, даун? Кафка пишет сообщения во все реплики, которые в любой момент времени могут отвалиться и сообщение потеряется. Если реплик нет, то проёб кафки - проёб всего.
Ахахах, ты же даже не понимаешь что сообщение может проебаться при смене лидера. Какой же даун, нахуй ты вообще в эликсир полез, если думаешь что сообщение на диске это гарантия?
В моей охуенной БД есть ACID, в отличии от кафки которая даже на диск не может записать и не проебаться.
А потом кафка отрубается и ты теряешь все записи нахуй, повезёт если за 3 минуты. Молодец, даун, опять нафантазировал обосранную хуету.
Кого ты поставил на место, обоссанец? С твоими знаниями ты можешь только себя поставить на место петуха возле параши, там место опущенцев которые вместо программирования баззворды хуячат и создают дерьмище с редисами, постгресами и кафками.
> Мне к этому нечего добавить, жаль тебя, я не понимаю нахуя ты в тред какую-то хуйню пишешь. Я уже начал думать что ты реально страдаешь чем-то вроде слабоумия или какого-то другого синдрома, где больные хуйню несут неконтроллируемо.
Неприятно, обоссанец? Конечно тебе неприятно, ведь вместо нормальных технологий ты переваренный кал хуячишь.
> дедуля
Хм, а ведь анон был прав, что ты студент который ни дня не работал, только фантазируешь в этом итт треде, лол
> Блять ну вот как тебе объяснить, что я посылаю апи запрос, кафка пишет сообщение на диск и только после этого посылает ответ.
Что ты несешь, даун? Кафка пишет сообщения во все реплики, которые в любой момент времени могут отвалиться и сообщение потеряется. Если реплик нет, то проёб кафки - проёб всего.
> Если я получил ответ, то сообщение на диске, ты это-то понимаешь той хуйнёй, что вот чуть-чуть выше дырочки на голове, куда ты свой кал кладёшь пожевать? Куда оно с диска проебётся?
Ахахах, ты же даже не понимаешь что сообщение может проебаться при смене лидера. Какой же даун, нахуй ты вообще в эликсир полез, если думаешь что сообщение на диске это гарантия?
> Вот же дегенерат. Это к твоей ахуенной маня-БД применимо, а к кафке нет,
В моей охуенной БД есть ACID, в отличии от кафки которая даже на диск не может записать и не проебаться.
> Когда я посылаю сообщение на запись, я рядом с ним посылаю уникальный номер. Кафка этот номер тоже записывает на какое-то время, поэтому когда я ретрайну запись, я ретрайну её с этим же номером и кафка быстро проверит, дубликат это записи или нет.
А потом кафка отрубается и ты теряешь все записи нахуй, повезёт если за 3 минуты. Молодец, даун, опять нафантазировал обосранную хуету.
> Вот точно есть какое-то заболевание. Сначала сам спизданул какую-то хуйню, его поставили на место, ведь аргументов ноль.
Кого ты поставил на место, обоссанец? С твоими знаниями ты можешь только себя поставить на место петуха возле параши, там место опущенцев которые вместо программирования баззворды хуячат и создают дерьмище с редисами, постгресами и кафками.
>>474258
Неприятно, обоссанец? Конечно тебе неприятно, ведь вместо нормальных технологий ты переваренный кал хуячишь.
Хм, а ведь анон был прав, что ты студент который ни дня не работал, только фантазируешь в этом итт треде, лол
Что ты несешь, даун? Кафка пишет сообщения во все реплики, которые в любой момент времени могут отвалиться и сообщение потеряется. Если реплик нет, то проёб кафки - проёб всего.
Ахахах, ты же даже не понимаешь что сообщение может проебаться при смене лидера. Какой же даун, нахуй ты вообще в эликсир полез, если думаешь что сообщение на диске это гарантия?
В моей охуенной БД есть ACID, в отличии от кафки которая даже на диск не может записать и не проебаться.
А потом кафка отрубается и ты теряешь все записи нахуй, повезёт если за 3 минуты. Молодец, даун, опять нафантазировал обосранную хуету.
Кого ты поставил на место, обоссанец? С твоими знаниями ты можешь только себя поставить на место петуха возле параши, там место опущенцев которые вместо программирования баззворды хуячат и создают дерьмище с редисами, постгресами и кафками.
> Мне к этому нечего добавить, жаль тебя, я не понимаю нахуя ты в тред какую-то хуйню пишешь. Я уже начал думать что ты реально страдаешь чем-то вроде слабоумия или какого-то другого синдрома, где больные хуйню несут неконтроллируемо.
Неприятно, обоссанец? Конечно тебе неприятно, ведь вместо нормальных технологий ты переваренный кал хуячишь.
> дедуля
Хм, а ведь анон был прав, что ты студент который ни дня не работал, только фантазируешь в этом итт треде, лол
> Блять ну вот как тебе объяснить, что я посылаю апи запрос, кафка пишет сообщение на диск и только после этого посылает ответ.
Что ты несешь, даун? Кафка пишет сообщения во все реплики, которые в любой момент времени могут отвалиться и сообщение потеряется. Если реплик нет, то проёб кафки - проёб всего.
> Если я получил ответ, то сообщение на диске, ты это-то понимаешь той хуйнёй, что вот чуть-чуть выше дырочки на голове, куда ты свой кал кладёшь пожевать? Куда оно с диска проебётся?
Ахахах, ты же даже не понимаешь что сообщение может проебаться при смене лидера. Какой же даун, нахуй ты вообще в эликсир полез, если думаешь что сообщение на диске это гарантия?
> Вот же дегенерат. Это к твоей ахуенной маня-БД применимо, а к кафке нет,
В моей охуенной БД есть ACID, в отличии от кафки которая даже на диск не может записать и не проебаться.
> Когда я посылаю сообщение на запись, я рядом с ним посылаю уникальный номер. Кафка этот номер тоже записывает на какое-то время, поэтому когда я ретрайну запись, я ретрайну её с этим же номером и кафка быстро проверит, дубликат это записи или нет.
А потом кафка отрубается и ты теряешь все записи нахуй, повезёт если за 3 минуты. Молодец, даун, опять нафантазировал обосранную хуету.
> Вот точно есть какое-то заболевание. Сначала сам спизданул какую-то хуйню, его поставили на место, ведь аргументов ноль.
Кого ты поставил на место, обоссанец? С твоими знаниями ты можешь только себя поставить на место петуха возле параши, там место опущенцев которые вместо программирования баззворды хуячат и создают дерьмище с редисами, постгресами и кафками.
>>474297
А, ну больше и нечего добавить, я вот чувствовал что по ту сторону сидит безумный свидетель оракла. Да-да, очень важно услышать ваше мнение, продолжайте
Если ты реально думаешь что там настолько тупая репликация, то ты реально конченный дебил.
Сообщение не может проебаться при смене лидера, лол. Как она по-твоему происходит?
Я кажется понимаю в чём проблема: мы говорим о разных кафках. Я говорю про Apache Kafka, которой пользуется весь мир: с идемпотентностью, с reliable replication, с записью на диск. А ты говоришь про кафку, которую сам придумал, где просто веером рассылаются сообщения по кластеру и т.д.
Кароче, я не хочу тебя обижать сильно, ведь сразу видно что у тебя не в порядке с умом что-то, поэтому скажу что ты во всём-всём-всём прав. Твоя кафка теряет сообщения, твоя кафка не умеет реплицироваться, твоя кафка не умеет в мастер-мастер репликацию. И мне очень повезло, что твоя кафка существует только у тебя в манямирке. В том самом манямирке, где оракл бд в 20 раз быстрее редиса, и заменяет весь софт на свете. В этом прекрасном мире нет болезней, нет голода, нет войн. Оракл в этом мире стоит каменным обелиском и своим взором заменяет весь софт на оракл, и не только софт. Всё есть оракл, я есть оракл, ты есть оракл. И даже небо, даже Аллах...
>> дедуля
А, ну больше и нечего добавить, я вот чувствовал что по ту сторону сидит безумный свидетель оракла. Да-да, очень важно услышать ваше мнение, продолжайте
> пишет сообщения во все реплики
Если ты реально думаешь что там настолько тупая репликация, то ты реально конченный дебил.
> сообщение может проебаться при смене лидера
Сообщение не может проебаться при смене лидера, лол. Как она по-твоему происходит?
Я кажется понимаю в чём проблема: мы говорим о разных кафках. Я говорю про Apache Kafka, которой пользуется весь мир: с идемпотентностью, с reliable replication, с записью на диск. А ты говоришь про кафку, которую сам придумал, где просто веером рассылаются сообщения по кластеру и т.д.
Кароче, я не хочу тебя обижать сильно, ведь сразу видно что у тебя не в порядке с умом что-то, поэтому скажу что ты во всём-всём-всём прав. Твоя кафка теряет сообщения, твоя кафка не умеет реплицироваться, твоя кафка не умеет в мастер-мастер репликацию. И мне очень повезло, что твоя кафка существует только у тебя в манямирке. В том самом манямирке, где оракл бд в 20 раз быстрее редиса, и заменяет весь софт на свете. В этом прекрасном мире нет болезней, нет голода, нет войн. Оракл в этом мире стоит каменным обелиском и своим взором заменяет весь софт на оракл, и не только софт. Всё есть оракл, я есть оракл, ты есть оракл. И даже небо, даже Аллах...
>>474313
Пиздец фантазёр, уже придумал про меня целую историю как я дерьмищем типо оракла пользуюсь, лолд
И это всё что ты смог высрать? Как жалко.
Вот это малютка совсем зафантазировался совсем!
Из-за того что кафка и БД это две разных системы, дебил, смена лидера может возникнуть после успешной отправки старого лидера, хотя данные закомитились в БД или отправлены дальше.
И ведь это речь идёт про идеальный случай, с ask=all и прочим дерьмом в сообщениях, когда кластер работает как обосранный слоупок, все окна минимальны или соответствуют одному сообщению.
Ты говоришь про кафку которая волшебным образом сохраняет сообщение, через веру в магические дегенеративные маняфантазии. Что поделать, если ты малолетний дегенерат который не понимает в принципе как устроена сети и кафка, откуда тебе знать что каждое падение может исказить всю инфраструктуру.
>А, ну больше и нечего добавить, я вот чувствовал что по ту сторону сидит безумный свидетель оракла. Да-да, очень важно услышать ваше мнение, продолжайте
Пиздец фантазёр, уже придумал про меня целую историю как я дерьмищем типо оракла пользуюсь, лолд
> Если ты реально думаешь что там настолько тупая репликация, то ты реально конченный дебил.
И это всё что ты смог высрать? Как жалко.
> Сообщение не может проебаться при смене лидера, лол.
Вот это малютка совсем зафантазировался совсем!
> Как она по-твоему происходит?
Из-за того что кафка и БД это две разных системы, дебил, смена лидера может возникнуть после успешной отправки старого лидера, хотя данные закомитились в БД или отправлены дальше.
И ведь это речь идёт про идеальный случай, с ask=all и прочим дерьмом в сообщениях, когда кластер работает как обосранный слоупок, все окна минимальны или соответствуют одному сообщению.
> Я кажется понимаю в чём проблема: мы говорим о разных кафках. Я говорю про Apache Kafka,
Ты говоришь про кафку которая волшебным образом сохраняет сообщение, через веру в магические дегенеративные маняфантазии. Что поделать, если ты малолетний дегенерат который не понимает в принципе как устроена сети и кафка, откуда тебе знать что каждое падение может исказить всю инфраструктуру.
>>474477
Причём тут БД, еблан. Я про кафку пишу. Смена лидера там происходит через Raft-консенсус. То есть чтобы он не завершился за конечное время, надо быть очень невезучим. А пока происходит leader election, данные не теряются, потому что запись зависает. Даже если leader election начнётся во время записи, моя операция записи либо наебнётся и вернёт ошибку, либо завершится успешно с записью в лидере и репликах.
Ну вот и всё что нужно знать про твой уровень знаний. То есть ты сам признаёшь что ты обосрался. С acks=all у меня гарантия от каждой реплики что запись произошла. То есть если лидер умрёт после такой записи или реплика умрёт, но останется кворум, у меня не проебутся данные. И как бы ты не пиздел, кластер от этого не становится медленнее. Увеличивается латенси одной операции записи, но throughput не меняется, потому что ack с реплик это практически бесплатно. Если тебе нужен низкий латенси, то тебе изначально не в кафку.
> Из-за того что кафка и БД это две разных системы, дебил, смена лидера может возникнуть после успешной отправки старого лидера, хотя данные закомитились в БД или отправлены дальше.
Причём тут БД, еблан. Я про кафку пишу. Смена лидера там происходит через Raft-консенсус. То есть чтобы он не завершился за конечное время, надо быть очень невезучим. А пока происходит leader election, данные не теряются, потому что запись зависает. Даже если leader election начнётся во время записи, моя операция записи либо наебнётся и вернёт ошибку, либо завершится успешно с записью в лидере и репликах.
> ask=all
Ну вот и всё что нужно знать про твой уровень знаний. То есть ты сам признаёшь что ты обосрался. С acks=all у меня гарантия от каждой реплики что запись произошла. То есть если лидер умрёт после такой записи или реплика умрёт, но останется кворум, у меня не проебутся данные. И как бы ты не пиздел, кластер от этого не становится медленнее. Увеличивается латенси одной операции записи, но throughput не меняется, потому что ack с реплик это практически бесплатно. Если тебе нужен низкий латенси, то тебе изначально не в кафку.
>>474531
У тебя кафка существует в отдельном манямирке без транзакций?
Нет, потому что существует параметр с максимальными репликами, я не помню как он называется, ну да и похуй. Он вроде бы работает как раз с аскалл. А может и нет, я нихуя не помню, последний раз кафку трогал лет 10 назад. Если топология говна, то часть реплик внезапно отваливается и отваливаются как раз по этому разделу, данные либо проёбываются полностью, либо нахуй вся сеть недоступна становится. Кластер говна, гениальное решение.
Мне нужен менее говноедский стек, чтобы я не городил кафку через редис через постгресс, была вечная доступность и конечная согласованность. Собственно, я его уже давно составил и работаю с ним, правда CRDT приходится писать вручную, да и похуй, потом перепишу код бд для кластера.
> Причём тут БД, еблан. Я про кафку пишу.
У тебя кафка существует в отдельном манямирке без транзакций?
> Ну вот и всё что нужно знать про твой уровень знаний. То есть ты сам признаёшь что ты обосрался. С acks=all у меня гарантия от каждой реплики что запись произошла.
Нет, потому что существует параметр с максимальными репликами, я не помню как он называется, ну да и похуй. Он вроде бы работает как раз с аскалл. А может и нет, я нихуя не помню, последний раз кафку трогал лет 10 назад. Если топология говна, то часть реплик внезапно отваливается и отваливаются как раз по этому разделу, данные либо проёбываются полностью, либо нахуй вся сеть недоступна становится. Кластер говна, гениальное решение.
> Если тебе нужен низкий латенси, то тебе изначально не в кафку.
Мне нужен менее говноедский стек, чтобы я не городил кафку через редис через постгресс, была вечная доступность и конечная согласованность. Собственно, я его уже давно составил и работаю с ним, правда CRDT приходится писать вручную, да и похуй, потом перепишу код бд для кластера.
>>474340
Это у шизика случилось обострение. Бери попкорн, будет весело.
Я лично проиграл, когда он начал задвигать, как в его волшебной субд (кстати где она) данные из памяти читаются в два раза быстрее. Ждем новых откровений от мастера.
Это у шизика случилось обострение. Бери попкорн, будет весело.
Я лично проиграл, когда он начал задвигать, как в его волшебной субд (кстати где она) данные из памяти читаются в два раза быстрее. Ждем новых откровений от мастера.
>>474547
Я вообще о транзакциях ни слова не говорил. Ты сказал что кафка проёбывает данные если их в неё просто писать. Ни слова про транзакции. Вот я запруфал что это нихуя не так. Как и то что дубликаты будут, я тоже запруфал что это нихуя не так.
Нихуя не понял что ты сейчас написал. Какая топология? Как падение кафок за собой сеть кладёт? Какому разделу? Что ты вообще несёшь?
Блять ну я тебе уже в третий раз поясняю, что мне поебать на твоё мнение про стек и архитектуры и прочий кал. Я спорю только с двумя утверждениями "кафка проёбывает данные в любой конфигурации" и "существует какая-то SQL-манябд, где чтение по ключу в два раза быстрее чем из Redis".
По кафке я тебя уже разъебал, аргументов у тебя нет. По редису ты слился, потому что говоришь про вооброжаему манябд. Кароче, идёшь нахуй по всем параметрам, как я уже сказал, обратно в питонотред или в дом престарелых или откуда ты там вылез.
> У тебя кафка существует в отдельном манямирке без транзакций?
Я вообще о транзакциях ни слова не говорил. Ты сказал что кафка проёбывает данные если их в неё просто писать. Ни слова про транзакции. Вот я запруфал что это нихуя не так. Как и то что дубликаты будут, я тоже запруфал что это нихуя не так.
> Если топология говна, то часть реплик внезапно отваливается и отваливаются как раз по этому разделу, данные либо проёбываются полностью, либо нахуй вся сеть недоступна становится.
Нихуя не понял что ты сейчас написал. Какая топология? Как падение кафок за собой сеть кладёт? Какому разделу? Что ты вообще несёшь?
> Мне нужен менее говноедский стек, чтобы я не городил кафку через редис через постгресс
Блять ну я тебе уже в третий раз поясняю, что мне поебать на твоё мнение про стек и архитектуры и прочий кал. Я спорю только с двумя утверждениями "кафка проёбывает данные в любой конфигурации" и "существует какая-то SQL-манябд, где чтение по ключу в два раза быстрее чем из Redis".
По кафке я тебя уже разъебал, аргументов у тебя нет. По редису ты слился, потому что говоришь про вооброжаему манябд. Кароче, идёшь нахуй по всем параметрам, как я уже сказал, обратно в питонотред или в дом престарелых или откуда ты там вылез.
>>474617
Понимаю, ты слишком слаб разумом чтобы это принять. Но поверь мне, я действительно читаю данные в два раза быстрее редиса. Линейная зависимость. Тут нет никакой магии, которая существует в твоей тупой бошке.
Всё дело в том, что у меня нет посторонних данных в запросе. У тебя же, при каждом запросе, запрос переполнен бессмысленной и бесполезной информацией.
>>474649
В принципе да, если не делать аск=алл, и редко кто это будет делать потому что это не эффективно.
Сетевая, очевидно. При настройках которые обеспечивают высокую доступность разные потребители и производители могут оказаться с разных сторон сетевого раздела и начать проёбывать данные, например из-за нарушений последовательности.
Если IPS меньше минимальных реплик, то кластер начнёт выдавать исключения, дебил.
Т.е. ты споришь сам с собой? Продолжай, буду наблюдать за твоей клоунадой.
Разъебал ты тут только свою сраку, разорвавшись на весь тред. Забавно вышло, лол
Понимаю, ты слишком слаб разумом чтобы это принять. Но поверь мне, я действительно читаю данные в два раза быстрее редиса. Линейная зависимость. Тут нет никакой магии, которая существует в твоей тупой бошке.
Всё дело в том, что у меня нет посторонних данных в запросе. У тебя же, при каждом запросе, запрос переполнен бессмысленной и бесполезной информацией.
>>474649
> Я вообще о транзакциях ни слова не говорил. Ты сказал что кафка проёбывает данные если их в неё просто писать.
В принципе да, если не делать аск=алл, и редко кто это будет делать потому что это не эффективно.
> Нихуя не понял что ты сейчас написал. Какая топология?
Сетевая, очевидно. При настройках которые обеспечивают высокую доступность разные потребители и производители могут оказаться с разных сторон сетевого раздела и начать проёбывать данные, например из-за нарушений последовательности.
> Как падение кафок за собой сеть кладёт? Какому разделу? Что ты вообще несёшь?
Если IPS меньше минимальных реплик, то кластер начнёт выдавать исключения, дебил.
> Блять ну я тебе уже в третий раз поясняю, что мне поебать на твоё мнение про стек и архитектуры и прочий кал. Я спорю только с двумя утверждениями "кафка проёбывает данные в любой конфигурации" и "существует какая-то SQL-манябд, где чтение по ключу в два раза быстрее чем из Redis".
Т.е. ты споришь сам с собой? Продолжай, буду наблюдать за твоей клоунадой.
> По кафке я тебя уже разъебал, аргументов у тебя нет.
Разъебал ты тут только свою сраку, разорвавшись на весь тред. Забавно вышло, лол
>>474752
То есть, ты читаешь из памяти в два раза быстрее, чем это делает контроллер памяти? Такая-то шизомагия!
У меня есть ключ, по которому я получаю значение из редиса. Что из этого является бесполезной информацией, шиз?
>Но поверь мне, я действительно читаю данные в два раза быстрее редиса.
То есть, ты читаешь из памяти в два раза быстрее, чем это делает контроллер памяти? Такая-то шизомагия!
>Всё дело в том, что у меня нет посторонних данных в запросе. У тебя же, при каждом запросе, запрос переполнен бессмысленной и бесполезной информацией.
У меня есть ключ, по которому я получаю значение из редиса. Что из этого является бесполезной информацией, шиз?
>>474784
И что и чего. Главное что всё это говнище для дегенератов застрявших в 2012 году.
>>474941
Нет, я читаю в два раза быстрее потому что у меня в два раза меньше данных, дегенерат.
Значит про кафку и sql ты решил моментально забыть? Удобно для обоссаного петушка с фантазиями про отсталый стек - забывать неприятное.
И что и чего. Главное что всё это говнище для дегенератов застрявших в 2012 году.
>>474941
>То есть, ты читаешь из памяти в два раза быстрее, чем это делает контроллер памяти? Такая-то шизомагия!
Нет, я читаю в два раза быстрее потому что у меня в два раза меньше данных, дегенерат.
>У меня есть ключ, по которому я получаю значение из редиса. Что из этого является бесполезной информацией, шиз?
Значит про кафку и sql ты решил моментально забыть? Удобно для обоссаного петушка с фантазиями про отсталый стек - забывать неприятное.
>>475040
Итак мы выяснили, что шизомагия делает данные вдвое меньше. Продолжаем наблюдение на пациентом.
По кафе я тебе обоссу завтра, сегодня ты получаешь урину за редис.
Итак мы выяснили, что шизомагия делает данные вдвое меньше. Продолжаем наблюдение на пациентом.
По кафе я тебе обоссу завтра, сегодня ты получаешь урину за редис.
>>475121
@
Уже как-то не смешно даже с тебя, отрицание реальности пошло. Может ты вообще не сечёшь в технологиях и не понимаешь из чего состоят сообщения, что скрывает за идемпотентностью и чем обеспечивается последовательность?
Погоди, это получается ты реально малолетний студентик-обоссанец который зачем-то дрочит на эликсир? Мда.
> У тебя, говноедище, куча бесполезных данных данных - sql в запросах, индексы, идентификаторы к каждому сообщению. У меня этого нет, потому что я не каложуй.
@
> РЯЯ ВРЁТИ НЕТУ ТЫ ГОВОРИШЬ ПРО МАГИЮ!11
Уже как-то не смешно даже с тебя, отрицание реальности пошло. Может ты вообще не сечёшь в технологиях и не понимаешь из чего состоят сообщения, что скрывает за идемпотентностью и чем обеспечивается последовательность?
Погоди, это получается ты реально малолетний студентик-обоссанец который зачем-то дрочит на эликсир? Мда.
>>475187
Животное, в редисе нет sql запросов. Ты окончательно ебанулся. Прими таблетки и не визжи, а то снова мамка в дурку сдаст.
Животное, в редисе нет sql запросов. Ты окончательно ебанулся. Прими таблетки и не визжи, а то снова мамка в дурку сдаст.
>>475311
Ого, у тебя неслабые ментальные проблемы, ты уже забыл что именно ты писал про постгрес с сридисом.
С тобой всё хорошо, обоссанец? Почему ты больше не способен поддерживать даже примитивный диалог? Это из-за бесконечных унижений и потока мочи, которая покрывает тебя и этот тред полностью?
Ого, у тебя неслабые ментальные проблемы, ты уже забыл что именно ты писал про постгрес с сридисом.
С тобой всё хорошо, обоссанец? Почему ты больше не способен поддерживать даже примитивный диалог? Это из-за бесконечных унижений и потока мочи, которая покрывает тебя и этот тред полностью?
>>474752
Я вернулся тебя разъебывать, родной.
Это эффективно. От этого растёт латенси на запись, но общий throughput не меняется. Единственная экстра операция, которая происходит с acks=all это то что реплики отсылают ack тоже, а это считай бесплатная вещь в кластере кафки.
Какого нахуй сетевого раздела. Я тебя сейчас один вещь скажу, ты только не обижайся, но кафка реплицируется нормально даже когда реплики в разных датацентрах.
Что такое IPS? Intrusion prevention system? Или ты хотел сказать что IP адресов меньше чем минимальных реплик? Эту хуйню я не понял.
Я спорю с хуйнёй написанной вот тут
>>472578
И я всё ещё жду, когда ты мне бенчмарк покажешь. Бенчмарк записи в свою манябд, по сравнению с записью в кафку и в редис.
Я вернулся тебя разъебывать, родной.
> В принципе да, если не делать аск=алл, и редко кто это будет делать потому что это не эффективно.
Это эффективно. От этого растёт латенси на запись, но общий throughput не меняется. Единственная экстра операция, которая происходит с acks=all это то что реплики отсылают ack тоже, а это считай бесплатная вещь в кластере кафки.
> Сетевая, очевидно. При настройках которые обеспечивают высокую доступность разные потребители и производители могут оказаться с разных сторон сетевого раздела и начать проёбывать данные, например из-за нарушений последовательности.
Какого нахуй сетевого раздела. Я тебя сейчас один вещь скажу, ты только не обижайся, но кафка реплицируется нормально даже когда реплики в разных датацентрах.
> Если IPS меньше минимальных реплик, то кластер начнёт выдавать исключения, дебил.
Что такое IPS? Intrusion prevention system? Или ты хотел сказать что IP адресов меньше чем минимальных реплик? Эту хуйню я не понял.
> Т.е. ты споришь сам с собой? Продолжай, буду наблюдать за твоей клоунадой.
Я спорю с хуйнёй написанной вот тут
>>472578
>Нет, так же как и из БД, если брать БД достаточно производительные - чтение даже быстрее чем в редисе.
>[Кафка] может внезапно упасть. Если твоя задача проебать данные - можешь смело заниматься этим.
И я всё ещё жду, когда ты мне бенчмарк покажешь. Бенчмарк записи в свою манябд, по сравнению с записью в кафку и в редис.
>>471523
Да, я тут слегка посидел попереписывался с нейросеткой, сошлись к тому, что лучший способ персистентности для BEAM — это приклеить сбоку готовую СУБД. Вроде кто-то пытался засунуть внутрь RocksDB и LevelDB, но получилось как-то грустно.
Дело в том, что система-оркестратор, обеспечивающая обработку данных, обязана (ОБЯЗАНА блять) организовывать консистентную и отказоустойчивую обработку этих самых данных. Да, какую-то долю базовых гарантий даёт СУБД, но на уровне системы в сборе нужно обеспечивать гарантии, которых в каждом отдельном звене нету.
Особенно это касается алгоритмов с требованиями к строгой линеааризуемости, потому что в общем случае комбинация двух линеаризуемых компонентов нелинеаризуема — нужны дополнительные болты-шестерёнки, чтобы добиться линеаризуемости комбинации.
Почти все современное распределённые key-value СУБД, включая шины сообщений — это надстройки над LSM-подобным хранилищем, вроде упомянутого RocksDB. Имея в распоряжении LSM хранилище и инструмент реализации надёжного алгоритма можно реализовать систему с какой угодно консистентностью, разные варианты CRDT с eventual consistency, и при этом параллельно на тех же датасетах делать операции со строго линеаризуемостью, причём, по желанию, на уровне ключа, набора ключей, или всей таблицы. В том числе на этом фреймворке можно реализовать варианты Raft/Zab/Multipaxos с Master-Slave, если вспомнить, что это не более чем тупые хранилища логов и стоящий сбоку координатор (Master, или lease holder в терминологии гугла). Slave не выполняет никаких активных функций вне выборов, если что.
Так вот мы посидели тут с нейросеткой и подумали, нахуй нужен инструмент, который претендует на роль оркестратора, но не способен организовывать хранение данных. И пришли к выводу, что, в общем-то, для типового современного вебсайта, который показывает контент и работает с CRUD хуйнёй от пользователя, BEAM оказывается как третья нога, прокладка между БД и браузером, которую можно написать с таким же успехом на PHP/Ruby/Python/JS/Go — причём, что характерно, на Go таки можно написать тяжёлые числодробилки и СУБД, как та же BadgerDB. То есть, именно Golang на роль затычки в каждой бочке подходит намного лучше, чем Erlang/Elixir. Для Erlang/Elixir же остёются свои узкие нишы, в которых они хороши — это система из кучи неперсистентных активно и сложно взаимодействующих задач, вроде чатиков, совместной работы, трейдинга (не путать с банальной покупкой в интернет-магазе), то есть, много пользователей делающих последовательности простых действий.
>Кстати это полный кал, никому не советую его использовать. Запись туда не durable, не атомарна и ещё и можно проебать запись потому что оно пишется сначала в кэш
Да, я тут слегка посидел попереписывался с нейросеткой, сошлись к тому, что лучший способ персистентности для BEAM — это приклеить сбоку готовую СУБД. Вроде кто-то пытался засунуть внутрь RocksDB и LevelDB, но получилось как-то грустно.
>Вообще в целом твой пост какой-то как будто ты свою телегу какую-то пишешь и к моему посту она слабо относится, как и вообще к Elixir. Причём тут редисы, кафки, постгри и вся хуйня, какие ещё гуглы и фейсбуки...
Дело в том, что система-оркестратор, обеспечивающая обработку данных, обязана (ОБЯЗАНА блять) организовывать консистентную и отказоустойчивую обработку этих самых данных. Да, какую-то долю базовых гарантий даёт СУБД, но на уровне системы в сборе нужно обеспечивать гарантии, которых в каждом отдельном звене нету.
Особенно это касается алгоритмов с требованиями к строгой линеааризуемости, потому что в общем случае комбинация двух линеаризуемых компонентов нелинеаризуема — нужны дополнительные болты-шестерёнки, чтобы добиться линеаризуемости комбинации.
Почти все современное распределённые key-value СУБД, включая шины сообщений — это надстройки над LSM-подобным хранилищем, вроде упомянутого RocksDB. Имея в распоряжении LSM хранилище и инструмент реализации надёжного алгоритма можно реализовать систему с какой угодно консистентностью, разные варианты CRDT с eventual consistency, и при этом параллельно на тех же датасетах делать операции со строго линеаризуемостью, причём, по желанию, на уровне ключа, набора ключей, или всей таблицы. В том числе на этом фреймворке можно реализовать варианты Raft/Zab/Multipaxos с Master-Slave, если вспомнить, что это не более чем тупые хранилища логов и стоящий сбоку координатор (Master, или lease holder в терминологии гугла). Slave не выполняет никаких активных функций вне выборов, если что.
Так вот мы посидели тут с нейросеткой и подумали, нахуй нужен инструмент, который претендует на роль оркестратора, но не способен организовывать хранение данных. И пришли к выводу, что, в общем-то, для типового современного вебсайта, который показывает контент и работает с CRUD хуйнёй от пользователя, BEAM оказывается как третья нога, прокладка между БД и браузером, которую можно написать с таким же успехом на PHP/Ruby/Python/JS/Go — причём, что характерно, на Go таки можно написать тяжёлые числодробилки и СУБД, как та же BadgerDB. То есть, именно Golang на роль затычки в каждой бочке подходит намного лучше, чем Erlang/Elixir. Для Erlang/Elixir же остёются свои узкие нишы, в которых они хороши — это система из кучи неперсистентных активно и сложно взаимодействующих задач, вроде чатиков, совместной работы, трейдинга (не путать с банальной покупкой в интернет-магазе), то есть, много пользователей делающих последовательности простых действий.
>>471523
Да, я тут слегка посидел попереписывался с нейросеткой, сошлись к тому, что лучший способ персистентности для BEAM — это приклеить сбоку готовую СУБД. Вроде кто-то пытался засунуть внутрь RocksDB и LevelDB, но получилось как-то грустно.
Дело в том, что система-оркестратор, обеспечивающая обработку данных, обязана (ОБЯЗАНА блять) организовывать консистентную и отказоустойчивую обработку этих самых данных. Да, какую-то долю базовых гарантий даёт СУБД, но на уровне системы в сборе нужно обеспечивать гарантии, которых в каждом отдельном звене нету.
Особенно это касается алгоритмов с требованиями к строгой линеааризуемости, потому что в общем случае комбинация двух линеаризуемых компонентов нелинеаризуема — нужны дополнительные болты-шестерёнки, чтобы добиться линеаризуемости комбинации.
Почти все современное распределённые key-value СУБД, включая шины сообщений — это надстройки над LSM-подобным хранилищем, вроде упомянутого RocksDB. Имея в распоряжении LSM хранилище и инструмент реализации надёжного алгоритма можно реализовать систему с какой угодно консистентностью, разные варианты CRDT с eventual consistency, и при этом параллельно на тех же датасетах делать операции со строго линеаризуемостью, причём, по желанию, на уровне ключа, набора ключей, или всей таблицы. В том числе на этом фреймворке можно реализовать варианты Raft/Zab/Multipaxos с Master-Slave, если вспомнить, что это не более чем тупые хранилища логов и стоящий сбоку координатор (Master, или lease holder в терминологии гугла). Slave не выполняет никаких активных функций вне выборов, если что.
Так вот мы посидели тут с нейросеткой и подумали, нахуй нужен инструмент, который претендует на роль оркестратора, но не способен организовывать хранение данных. И пришли к выводу, что, в общем-то, для типового современного вебсайта, который показывает контент и работает с CRUD хуйнёй от пользователя, BEAM оказывается как третья нога, прокладка между БД и браузером, которую можно написать с таким же успехом на PHP/Ruby/Python/JS/Go — причём, что характерно, на Go таки можно написать тяжёлые числодробилки и СУБД, как та же BadgerDB. То есть, именно Golang на роль затычки в каждой бочке подходит намного лучше, чем Erlang/Elixir. Для Erlang/Elixir же остёются свои узкие нишы, в которых они хороши — это система из кучи неперсистентных активно и сложно взаимодействующих задач, вроде чатиков, совместной работы, трейдинга (не путать с банальной покупкой в интернет-магазе), то есть, много пользователей делающих последовательности простых действий.
>Кстати это полный кал, никому не советую его использовать. Запись туда не durable, не атомарна и ещё и можно проебать запись потому что оно пишется сначала в кэш
Да, я тут слегка посидел попереписывался с нейросеткой, сошлись к тому, что лучший способ персистентности для BEAM — это приклеить сбоку готовую СУБД. Вроде кто-то пытался засунуть внутрь RocksDB и LevelDB, но получилось как-то грустно.
>Вообще в целом твой пост какой-то как будто ты свою телегу какую-то пишешь и к моему посту она слабо относится, как и вообще к Elixir. Причём тут редисы, кафки, постгри и вся хуйня, какие ещё гуглы и фейсбуки...
Дело в том, что система-оркестратор, обеспечивающая обработку данных, обязана (ОБЯЗАНА блять) организовывать консистентную и отказоустойчивую обработку этих самых данных. Да, какую-то долю базовых гарантий даёт СУБД, но на уровне системы в сборе нужно обеспечивать гарантии, которых в каждом отдельном звене нету.
Особенно это касается алгоритмов с требованиями к строгой линеааризуемости, потому что в общем случае комбинация двух линеаризуемых компонентов нелинеаризуема — нужны дополнительные болты-шестерёнки, чтобы добиться линеаризуемости комбинации.
Почти все современное распределённые key-value СУБД, включая шины сообщений — это надстройки над LSM-подобным хранилищем, вроде упомянутого RocksDB. Имея в распоряжении LSM хранилище и инструмент реализации надёжного алгоритма можно реализовать систему с какой угодно консистентностью, разные варианты CRDT с eventual consistency, и при этом параллельно на тех же датасетах делать операции со строго линеаризуемостью, причём, по желанию, на уровне ключа, набора ключей, или всей таблицы. В том числе на этом фреймворке можно реализовать варианты Raft/Zab/Multipaxos с Master-Slave, если вспомнить, что это не более чем тупые хранилища логов и стоящий сбоку координатор (Master, или lease holder в терминологии гугла). Slave не выполняет никаких активных функций вне выборов, если что.
Так вот мы посидели тут с нейросеткой и подумали, нахуй нужен инструмент, который претендует на роль оркестратора, но не способен организовывать хранение данных. И пришли к выводу, что, в общем-то, для типового современного вебсайта, который показывает контент и работает с CRUD хуйнёй от пользователя, BEAM оказывается как третья нога, прокладка между БД и браузером, которую можно написать с таким же успехом на PHP/Ruby/Python/JS/Go — причём, что характерно, на Go таки можно написать тяжёлые числодробилки и СУБД, как та же BadgerDB. То есть, именно Golang на роль затычки в каждой бочке подходит намного лучше, чем Erlang/Elixir. Для Erlang/Elixir же остёются свои узкие нишы, в которых они хороши — это система из кучи неперсистентных активно и сложно взаимодействующих задач, вроде чатиков, совместной работы, трейдинга (не путать с банальной покупкой в интернет-магазе), то есть, много пользователей делающих последовательности простых действий.
>>472550
ХЗ, кто тебя этому научил. Из всех шин сообщений кафка — одна из самых медленных, потому что обеспечивает больше всех гарантий по транзакционности и гарантиям однократной доставки. Саб отключается-подключается — всё встаёт колом на мгновение, пока координатор переконфигурирует partition-ы. Поставить/принять сообщение — ACID операция, жди подтверждения. То есть, никакого low latency и реального времени там нет — но некоторым людям приходит в голову использовать кафку для взаимодействия между сервисами, требовательными ко времени ответа, вроде немедленного REST запроса от клиентского устройства.
Нет никакой инфы о том, где яндекс собирает и обрабатывает эти данные, ни лично я бы не додумался эти естественно распределённые данные и процесы обработки хуярить в одну шину "потому что она у нас уже есть".
Я (>>471511) решил не писать, но так и быть, напишу. Редис и Memcached — это костыль для PHP/Ruby/Python/Perl, которые не умеют в многопоточность и разделяемое состояние. Собственно, Memcached создан специально под PHP для конкретные задачи. Ровно для той же цели создан ETS — без него платформа получилась бы совсем смешная и бесполезная, к ней точно так же пришлось бы подставлять подпорку из Redis/Memcachd на каждый пук, или лезть в постгрю на те же самые пуки.
Проблема вообще не в способности сервера РСУБД, а в персистентности. Если у тебя есть требование записи на диск синхронно по всему кластеру, то тебе нужно подождать и задержку сети, и задержку самого медленного диска — а это может быть довольно дохуя. In-RAM РСУБД с асинхронной репликацией может выдавать ебанутую производительность, но в плане персистентности — сам понимаешь, лучше мастер не терять никогда. Но даже если у тебя есть допущение "всегда есть работающий сервер, держущий данные в оперативе" и RAM = персистентность, то всё равно задержка синхронного комита по сети никуда не девается.
>Кафка нужна, чтобы быстро-быстро собирать инфу с дохуилиона датчиков в реальном времени.
ХЗ, кто тебя этому научил. Из всех шин сообщений кафка — одна из самых медленных, потому что обеспечивает больше всех гарантий по транзакционности и гарантиям однократной доставки. Саб отключается-подключается — всё встаёт колом на мгновение, пока координатор переконфигурирует partition-ы. Поставить/принять сообщение — ACID операция, жди подтверждения. То есть, никакого low latency и реального времени там нет — но некоторым людям приходит в голову использовать кафку для взаимодействия между сервисами, требовательными ко времени ответа, вроде немедленного REST запроса от клиентского устройства.
Нет никакой инфы о том, где яндекс собирает и обрабатывает эти данные, ни лично я бы не додумался эти естественно распределённые данные и процесы обработки хуярить в одну шину "потому что она у нас уже есть".
>Редис - это тупо кеш. Из него читать быстрее, чем из бд.
Я (>>471511) решил не писать, но так и быть, напишу. Редис и Memcached — это костыль для PHP/Ruby/Python/Perl, которые не умеют в многопоточность и разделяемое состояние. Собственно, Memcached создан специально под PHP для конкретные задачи. Ровно для той же цели создан ETS — без него платформа получилась бы совсем смешная и бесполезная, к ней точно так же пришлось бы подставлять подпорку из Redis/Memcachd на каждый пук, или лезть в постгрю на те же самые пуки.
>Можно сделать систему чисто на одной бд, но тогда твой сервер просто выдержит меньше рпс. Другой вопрос: а будет ли у говносайта говнопиццы столько рпс, чтобы понадобилась кафка.
Проблема вообще не в способности сервера РСУБД, а в персистентности. Если у тебя есть требование записи на диск синхронно по всему кластеру, то тебе нужно подождать и задержку сети, и задержку самого медленного диска — а это может быть довольно дохуя. In-RAM РСУБД с асинхронной репликацией может выдавать ебанутую производительность, но в плане персистентности — сам понимаешь, лучше мастер не терять никогда. Но даже если у тебя есть допущение "всегда есть работающий сервер, держущий данные в оперативе" и RAM = персистентность, то всё равно задержка синхронного комита по сети никуда не девается.
>>472550
ХЗ, кто тебя этому научил. Из всех шин сообщений кафка — одна из самых медленных, потому что обеспечивает больше всех гарантий по транзакционности и гарантиям однократной доставки. Саб отключается-подключается — всё встаёт колом на мгновение, пока координатор переконфигурирует partition-ы. Поставить/принять сообщение — ACID операция, жди подтверждения. То есть, никакого low latency и реального времени там нет — но некоторым людям приходит в голову использовать кафку для взаимодействия между сервисами, требовательными ко времени ответа, вроде немедленного REST запроса от клиентского устройства.
Нет никакой инфы о том, где яндекс собирает и обрабатывает эти данные, ни лично я бы не додумался эти естественно распределённые данные и процесы обработки хуярить в одну шину "потому что она у нас уже есть".
Я (>>471511) решил не писать, но так и быть, напишу. Редис и Memcached — это костыль для PHP/Ruby/Python/Perl, которые не умеют в многопоточность и разделяемое состояние. Собственно, Memcached создан специально под PHP для конкретные задачи. Ровно для той же цели создан ETS — без него платформа получилась бы совсем смешная и бесполезная, к ней точно так же пришлось бы подставлять подпорку из Redis/Memcachd на каждый пук, или лезть в постгрю на те же самые пуки.
Проблема вообще не в способности сервера РСУБД, а в персистентности. Если у тебя есть требование записи на диск синхронно по всему кластеру, то тебе нужно подождать и задержку сети, и задержку самого медленного диска — а это может быть довольно дохуя. In-RAM РСУБД с асинхронной репликацией может выдавать ебанутую производительность, но в плане персистентности — сам понимаешь, лучше мастер не терять никогда. Но даже если у тебя есть допущение "всегда есть работающий сервер, держущий данные в оперативе" и RAM = персистентность, то всё равно задержка синхронного комита по сети никуда не девается.
>Кафка нужна, чтобы быстро-быстро собирать инфу с дохуилиона датчиков в реальном времени.
ХЗ, кто тебя этому научил. Из всех шин сообщений кафка — одна из самых медленных, потому что обеспечивает больше всех гарантий по транзакционности и гарантиям однократной доставки. Саб отключается-подключается — всё встаёт колом на мгновение, пока координатор переконфигурирует partition-ы. Поставить/принять сообщение — ACID операция, жди подтверждения. То есть, никакого low latency и реального времени там нет — но некоторым людям приходит в голову использовать кафку для взаимодействия между сервисами, требовательными ко времени ответа, вроде немедленного REST запроса от клиентского устройства.
Нет никакой инфы о том, где яндекс собирает и обрабатывает эти данные, ни лично я бы не додумался эти естественно распределённые данные и процесы обработки хуярить в одну шину "потому что она у нас уже есть".
>Редис - это тупо кеш. Из него читать быстрее, чем из бд.
Я (>>471511) решил не писать, но так и быть, напишу. Редис и Memcached — это костыль для PHP/Ruby/Python/Perl, которые не умеют в многопоточность и разделяемое состояние. Собственно, Memcached создан специально под PHP для конкретные задачи. Ровно для той же цели создан ETS — без него платформа получилась бы совсем смешная и бесполезная, к ней точно так же пришлось бы подставлять подпорку из Redis/Memcachd на каждый пук, или лезть в постгрю на те же самые пуки.
>Можно сделать систему чисто на одной бд, но тогда твой сервер просто выдержит меньше рпс. Другой вопрос: а будет ли у говносайта говнопиццы столько рпс, чтобы понадобилась кафка.
Проблема вообще не в способности сервера РСУБД, а в персистентности. Если у тебя есть требование записи на диск синхронно по всему кластеру, то тебе нужно подождать и задержку сети, и задержку самого медленного диска — а это может быть довольно дохуя. In-RAM РСУБД с асинхронной репликацией может выдавать ебанутую производительность, но в плане персистентности — сам понимаешь, лучше мастер не терять никогда. Но даже если у тебя есть допущение "всегда есть работающий сервер, держущий данные в оперативе" и RAM = персистентность, то всё равно задержка синхронного комита по сети никуда не девается.
>>472578
Бля, ну как бы мой "любимый" Facebook использует MySQL в качестве локальной СУБД, но на их масштабе уже даже глубоко шардированный мускуль не вывозит.
Что простая классическая СУБД может довольно долго всё вывозит без дополнительных движений жопы — это я полностью согласен. Но ёбля с фундаментально рассинхронизированными данными и CRDT — это спорное "преимущество" по сравнению с Redis/Memcached. Ты писал
На что я тебе и отвечаю — нихуя не "просто". В случае кэша ты часть read-only данных делаешь неконсистентными, а запись обычно напрямую в БД с валидацией производишь, а если у тебя целиком БД неконстистентна, то опция ACID-операций с заранее согласованными данными у тебя отваливается, у тебя все операции нужно тщательно проектировать.
Я как бы не спорю с тем, что предлагаемый тобой подход является наиболее перспективным в плане масштабируемости, но в плане разработки это весьма "сложно".
>CRDT, шарды и пакетная обработка решают эту проблему. Офк, всё зависит от того какая БД используется
Бля, ну как бы мой "любимый" Facebook использует MySQL в качестве локальной СУБД, но на их масштабе уже даже глубоко шардированный мускуль не вывозит.
Что простая классическая СУБД может довольно долго всё вывозит без дополнительных движений жопы — это я полностью согласен. Но ёбля с фундаментально рассинхронизированными данными и CRDT — это спорное "преимущество" по сравнению с Redis/Memcached. Ты писал
>Сервер просто пишет в БД с нескольких процессов и всё. Всё, больше ничего не нужно. Без всяких шуток.
На что я тебе и отвечаю — нихуя не "просто". В случае кэша ты часть read-only данных делаешь неконсистентными, а запись обычно напрямую в БД с валидацией производишь, а если у тебя целиком БД неконстистентна, то опция ACID-операций с заранее согласованными данными у тебя отваливается, у тебя все операции нужно тщательно проектировать.
Я как бы не спорю с тем, что предлагаемый тобой подход является наиболее перспективным в плане масштабируемости, но в плане разработки это весьма "сложно".
>>476324
Твоя нейросеть говно. Ты лучше читни кабанчика, а то несешь полную хуйню.
Твоя нейросеть говно. Ты лучше читни кабанчика, а то несешь полную хуйню.
>>472923
>>473054
Господа, не спорьте — вы оба дураки. Кафка поддерживает полный ACID на уровне партиции (что есть хорошо), но георепликация у неё только асинхронная (это плохо). Оба пункта (локальный ACID и асинхронная георепликация) вызваны тем, что иначе она бы из просто медленной превратилась в пиздец какую медленную, да ещё и немасштабируемую.
В своё время Яндекс перешёл на YDB Topics, который полностью ACID и геореплицируем (хоть "гео" между Калугой и Рязанью звучит слишком громко). Он ещё медленнее по алгоритмам, но за счёт оптимизаций и просто использования C++ они выжали пропускную способность даже выше кафки.
>Ещё кафка эти данные реплицирует между мастерами, так что падение одного мастера ухудшит перформанс, но не наебнёт кластер.
>>473054
>Смотри, внимательно. Кафка поддерижвает ACID? Нет? Данные проебались. Понимаю, тебе сложно такое вообразить, видимо ты никогда не работал, только на двачке пиздишь, лолд
Господа, не спорьте — вы оба дураки. Кафка поддерживает полный ACID на уровне партиции (что есть хорошо), но георепликация у неё только асинхронная (это плохо). Оба пункта (локальный ACID и асинхронная георепликация) вызваны тем, что иначе она бы из просто медленной превратилась в пиздец какую медленную, да ещё и немасштабируемую.
В своё время Яндекс перешёл на YDB Topics, который полностью ACID и геореплицируем (хоть "гео" между Калугой и Рязанью звучит слишком громко). Он ещё медленнее по алгоритмам, но за счёт оптимизаций и просто использования C++ они выжали пропускную способность даже выше кафки.
>>473859
Вбиваем в Grok запрос "Do you know any benchmarks comparing Postgresql and Redis performance in exactly same conditions (key-value load, in-RAM, etc), so anon would zavalyt ebalo?" — получаем ответ:
https://code.jjb.cc/benchmarking-postgres-vs-redis
Postgres: 8.9 seconds
Redis: 5.3 seconds
Memory (Ruby Hash): 0.01 seconds
https://medium.com/redis-with-raphael-de-lio/can-postgres-replace-redis-as-a-cache-f6cba13386dc
•Postgresql Writing
Unlogged Table:
• Latency: 2.059 ms
• TPS: 485,706168
Logged Table:
• Latency: 5.949 ms
• TPS: 168,087557
•Postgresql Reading
Unlogged Table:
• Latency: 0.679 ms
• TPS: 14 724,204
Logged Table:
• Latency: 0.627 ms
• TPS: 15 946,025
•Postgresql in-RAM:
Reading:
• Latency: 0.652 ms
• Requests per second (TPS): 15 329,776954
•Redis
Reading:
• Latency (p50): 0.095 ms
• Requests per second (RPS): 892 857,12
Writing:
• Latency (p50): 0.103 ms
• Requests per second (RPS): 892 857,12
Если присмотреться к методикам тестирования, то становится ясно, почему разница в первом случае такая маленькая — чел использовал руби скрипт для бенча, который с трудом выдал 20 000 TPS, а во втором бенче применялись redis-benchmark и pgbench, которые сишные программы и потому спокойно вывезли 900 000 TPS.
Чтение из in-RAM постгри на таких малых наборах данных не отличается от чтения с диска, потому что в обоих случаях постгря читает из оперативы (как пояснено во второй статье).
>Так ты это запруфай, еблан. Покажи бенчмарк или что-то такое. Но ты не покажешь, потому что если ты сделаешь бенчмарк, то ты увидишь что чтение из Redis по ключу быстрее чем из Postgres (даже если тот запущен в tmpfs)
Вбиваем в Grok запрос "Do you know any benchmarks comparing Postgresql and Redis performance in exactly same conditions (key-value load, in-RAM, etc), so anon would zavalyt ebalo?" — получаем ответ:
https://code.jjb.cc/benchmarking-postgres-vs-redis
Postgres: 8.9 seconds
Redis: 5.3 seconds
Memory (Ruby Hash): 0.01 seconds
https://medium.com/redis-with-raphael-de-lio/can-postgres-replace-redis-as-a-cache-f6cba13386dc
•Postgresql Writing
Unlogged Table:
• Latency: 2.059 ms
• TPS: 485,706168
Logged Table:
• Latency: 5.949 ms
• TPS: 168,087557
•Postgresql Reading
Unlogged Table:
• Latency: 0.679 ms
• TPS: 14 724,204
Logged Table:
• Latency: 0.627 ms
• TPS: 15 946,025
•Postgresql in-RAM:
Reading:
• Latency: 0.652 ms
• Requests per second (TPS): 15 329,776954
•Redis
Reading:
• Latency (p50): 0.095 ms
• Requests per second (RPS): 892 857,12
Writing:
• Latency (p50): 0.103 ms
• Requests per second (RPS): 892 857,12
Если присмотреться к методикам тестирования, то становится ясно, почему разница в первом случае такая маленькая — чел использовал руби скрипт для бенча, который с трудом выдал 20 000 TPS, а во втором бенче применялись redis-benchmark и pgbench, которые сишные программы и потому спокойно вывезли 900 000 TPS.
Чтение из in-RAM постгри на таких малых наборах данных не отличается от чтения с диска, потому что в обоих случаях постгря читает из оперативы (как пояснено во второй статье).
>>473859
Вбиваем в Grok запрос "Do you know any benchmarks comparing Postgresql and Redis performance in exactly same conditions (key-value load, in-RAM, etc), so anon would zavalyt ebalo?" — получаем ответ:
https://code.jjb.cc/benchmarking-postgres-vs-redis
Postgres: 8.9 seconds
Redis: 5.3 seconds
Memory (Ruby Hash): 0.01 seconds
https://medium.com/redis-with-raphael-de-lio/can-postgres-replace-redis-as-a-cache-f6cba13386dc
•Postgresql Writing
Unlogged Table:
• Latency: 2.059 ms
• TPS: 485,706168
Logged Table:
• Latency: 5.949 ms
• TPS: 168,087557
•Postgresql Reading
Unlogged Table:
• Latency: 0.679 ms
• TPS: 14 724,204
Logged Table:
• Latency: 0.627 ms
• TPS: 15 946,025
•Postgresql in-RAM:
Reading:
• Latency: 0.652 ms
• Requests per second (TPS): 15 329,776954
•Redis
Reading:
• Latency (p50): 0.095 ms
• Requests per second (RPS): 892 857,12
Writing:
• Latency (p50): 0.103 ms
• Requests per second (RPS): 892 857,12
Если присмотреться к методикам тестирования, то становится ясно, почему разница в первом случае такая маленькая — чел использовал руби скрипт для бенча, который с трудом выдал 20 000 TPS, а во втором бенче применялись redis-benchmark и pgbench, которые сишные программы и потому спокойно вывезли 900 000 TPS.
Чтение из in-RAM постгри на таких малых наборах данных не отличается от чтения с диска, потому что в обоих случаях постгря читает из оперативы (как пояснено во второй статье).
>Так ты это запруфай, еблан. Покажи бенчмарк или что-то такое. Но ты не покажешь, потому что если ты сделаешь бенчмарк, то ты увидишь что чтение из Redis по ключу быстрее чем из Postgres (даже если тот запущен в tmpfs)
Вбиваем в Grok запрос "Do you know any benchmarks comparing Postgresql and Redis performance in exactly same conditions (key-value load, in-RAM, etc), so anon would zavalyt ebalo?" — получаем ответ:
https://code.jjb.cc/benchmarking-postgres-vs-redis
Postgres: 8.9 seconds
Redis: 5.3 seconds
Memory (Ruby Hash): 0.01 seconds
https://medium.com/redis-with-raphael-de-lio/can-postgres-replace-redis-as-a-cache-f6cba13386dc
•Postgresql Writing
Unlogged Table:
• Latency: 2.059 ms
• TPS: 485,706168
Logged Table:
• Latency: 5.949 ms
• TPS: 168,087557
•Postgresql Reading
Unlogged Table:
• Latency: 0.679 ms
• TPS: 14 724,204
Logged Table:
• Latency: 0.627 ms
• TPS: 15 946,025
•Postgresql in-RAM:
Reading:
• Latency: 0.652 ms
• Requests per second (TPS): 15 329,776954
•Redis
Reading:
• Latency (p50): 0.095 ms
• Requests per second (RPS): 892 857,12
Writing:
• Latency (p50): 0.103 ms
• Requests per second (RPS): 892 857,12
Если присмотреться к методикам тестирования, то становится ясно, почему разница в первом случае такая маленькая — чел использовал руби скрипт для бенча, который с трудом выдал 20 000 TPS, а во втором бенче применялись redis-benchmark и pgbench, которые сишные программы и потому спокойно вывезли 900 000 TPS.
Чтение из in-RAM постгри на таких малых наборах данных не отличается от чтения с диска, потому что в обоих случаях постгря читает из оперативы (как пояснено во второй статье).
>>476302
Я пользовался rocksdb в Elixir. Ничего грустного, всё хорошо работает. Но другой вопрос зачем вообще встраивать хранилище на сервер, который запросы обрабатывает?
Сразу похуй на твоё мнение после этих слов. С тем же успехом я могу тоже нейросеткой тебе ответ сгенерить и высрать тонну дефолтного кала (который ты мне сейчас и высрал, игнорируя все аргументы, которые я написал выше). Поэтому повторюсь. Во-первых, Elixir даёт изоляцию ошибок. Во-вторых, Elixir тупо удобнее чем PHP/Python/Ruby/JS по тулингу, либам, перформансу. В-третьих, Elixir тупо лаконичнее и менее требовательный к инфраструктуре чем Go. В-четвёртых, в Elixir очень много изкоробки того, что в Go люди пишут сами.
Причём тут распределённые алгоритмы вообще? Причём тут embedded базы данных? Что ты вообще блять несёшь? Elixir это не база данных, Elixir это блять не кубернетес, Elixir это не либа с распределёнными алгоритмами, Elixir это не средство для линеаризации эвентов. Elixir это язык программирования и фреймворк для написания распределённых программ. Он решает за тебя самые банальные задачи распределённого мира и предлагает уже готовую акторную модель. То есть Elixir даёт тебе нормальные и настоящие акторы, мониторинг ресурсов, изоляцию ошибок, супервайзинг, поведения для стейтмашин и акторов, эффективный интерконнект, ультрапростой RPC, посылку любых данных между нодами (да, даже блять замыкания можно посылать), пакование любых структур в байты, систему релизов для hot-reload, телеметрию и трейсинг, тулинг для отладки систем во время их исполнения, причём всех видов: от трейсинга и профайлеров до точечного инспекта состояния и ещё тонны других полезных вещей. И это всё ахуенно высокого качества, best practice решения, обкатанные в продах в разных конфигурациях и в ебейших топологиях. А теперь посмотри что есть в Go. Ты бы на Go эти вещи писал с нуля или подключал как либы от васянов, у каждого из которых своё мнение на счёт того как должны выглядеть распределённые алгоритмы.
Я на Elixir могу просто подключиться в прод реплом, дёрнуть :sys.get_state над нужным процессом и найти причину ошибки. Я могу в Elixir без какой-либо телеметрии просто увидеть какой процесс у меня памяти много жрёт. Меня просто не ебут эти проблемы, я не сижу с потным ебалом и не обкладываюсь логами, try/catch-ами и прочим defensive калом, пытаясь предсказать где что-то может наебнуться. Я просто знаю, что я могу подключиться к ноде и найти любую ошибку в моменте.
> пытался засунуть внутрь RocksDB и LevelDB, но получилось как-то грустно.
Я пользовался rocksdb в Elixir. Ничего грустного, всё хорошо работает. Но другой вопрос зачем вообще встраивать хранилище на сервер, который запросы обрабатывает?
> попереписывался с нейросеткой
> посидели тут с нейросеткой и подумали
Сразу похуй на твоё мнение после этих слов. С тем же успехом я могу тоже нейросеткой тебе ответ сгенерить и высрать тонну дефолтного кала (который ты мне сейчас и высрал, игнорируя все аргументы, которые я написал выше). Поэтому повторюсь. Во-первых, Elixir даёт изоляцию ошибок. Во-вторых, Elixir тупо удобнее чем PHP/Python/Ruby/JS по тулингу, либам, перформансу. В-третьих, Elixir тупо лаконичнее и менее требовательный к инфраструктуре чем Go. В-четвёртых, в Elixir очень много изкоробки того, что в Go люди пишут сами.
> CRDT с eventual consistency
> Raft/Zab/Multipaxos с Master-Slave
> инструмент, который претендует на роль оркестратора
> не способен организовывать хранение данных
Причём тут распределённые алгоритмы вообще? Причём тут embedded базы данных? Что ты вообще блять несёшь? Elixir это не база данных, Elixir это блять не кубернетес, Elixir это не либа с распределёнными алгоритмами, Elixir это не средство для линеаризации эвентов. Elixir это язык программирования и фреймворк для написания распределённых программ. Он решает за тебя самые банальные задачи распределённого мира и предлагает уже готовую акторную модель. То есть Elixir даёт тебе нормальные и настоящие акторы, мониторинг ресурсов, изоляцию ошибок, супервайзинг, поведения для стейтмашин и акторов, эффективный интерконнект, ультрапростой RPC, посылку любых данных между нодами (да, даже блять замыкания можно посылать), пакование любых структур в байты, систему релизов для hot-reload, телеметрию и трейсинг, тулинг для отладки систем во время их исполнения, причём всех видов: от трейсинга и профайлеров до точечного инспекта состояния и ещё тонны других полезных вещей. И это всё ахуенно высокого качества, best practice решения, обкатанные в продах в разных конфигурациях и в ебейших топологиях. А теперь посмотри что есть в Go. Ты бы на Go эти вещи писал с нуля или подключал как либы от васянов, у каждого из которых своё мнение на счёт того как должны выглядеть распределённые алгоритмы.
Я на Elixir могу просто подключиться в прод реплом, дёрнуть :sys.get_state над нужным процессом и найти причину ошибки. Я могу в Elixir без какой-либо телеметрии просто увидеть какой процесс у меня памяти много жрёт. Меня просто не ебут эти проблемы, я не сижу с потным ебалом и не обкладываюсь логами, try/catch-ами и прочим defensive калом, пытаясь предсказать где что-то может наебнуться. Я просто знаю, что я могу подключиться к ноде и найти любую ошибку в моменте.
>>476302
Я пользовался rocksdb в Elixir. Ничего грустного, всё хорошо работает. Но другой вопрос зачем вообще встраивать хранилище на сервер, который запросы обрабатывает?
Сразу похуй на твоё мнение после этих слов. С тем же успехом я могу тоже нейросеткой тебе ответ сгенерить и высрать тонну дефолтного кала (который ты мне сейчас и высрал, игнорируя все аргументы, которые я написал выше). Поэтому повторюсь. Во-первых, Elixir даёт изоляцию ошибок. Во-вторых, Elixir тупо удобнее чем PHP/Python/Ruby/JS по тулингу, либам, перформансу. В-третьих, Elixir тупо лаконичнее и менее требовательный к инфраструктуре чем Go. В-четвёртых, в Elixir очень много изкоробки того, что в Go люди пишут сами.
Причём тут распределённые алгоритмы вообще? Причём тут embedded базы данных? Что ты вообще блять несёшь? Elixir это не база данных, Elixir это блять не кубернетес, Elixir это не либа с распределёнными алгоритмами, Elixir это не средство для линеаризации эвентов. Elixir это язык программирования и фреймворк для написания распределённых программ. Он решает за тебя самые банальные задачи распределённого мира и предлагает уже готовую акторную модель. То есть Elixir даёт тебе нормальные и настоящие акторы, мониторинг ресурсов, изоляцию ошибок, супервайзинг, поведения для стейтмашин и акторов, эффективный интерконнект, ультрапростой RPC, посылку любых данных между нодами (да, даже блять замыкания можно посылать), пакование любых структур в байты, систему релизов для hot-reload, телеметрию и трейсинг, тулинг для отладки систем во время их исполнения, причём всех видов: от трейсинга и профайлеров до точечного инспекта состояния и ещё тонны других полезных вещей. И это всё ахуенно высокого качества, best practice решения, обкатанные в продах в разных конфигурациях и в ебейших топологиях. А теперь посмотри что есть в Go. Ты бы на Go эти вещи писал с нуля или подключал как либы от васянов, у каждого из которых своё мнение на счёт того как должны выглядеть распределённые алгоритмы.
Я на Elixir могу просто подключиться в прод реплом, дёрнуть :sys.get_state над нужным процессом и найти причину ошибки. Я могу в Elixir без какой-либо телеметрии просто увидеть какой процесс у меня памяти много жрёт. Меня просто не ебут эти проблемы, я не сижу с потным ебалом и не обкладываюсь логами, try/catch-ами и прочим defensive калом, пытаясь предсказать где что-то может наебнуться. Я просто знаю, что я могу подключиться к ноде и найти любую ошибку в моменте.
> пытался засунуть внутрь RocksDB и LevelDB, но получилось как-то грустно.
Я пользовался rocksdb в Elixir. Ничего грустного, всё хорошо работает. Но другой вопрос зачем вообще встраивать хранилище на сервер, который запросы обрабатывает?
> попереписывался с нейросеткой
> посидели тут с нейросеткой и подумали
Сразу похуй на твоё мнение после этих слов. С тем же успехом я могу тоже нейросеткой тебе ответ сгенерить и высрать тонну дефолтного кала (который ты мне сейчас и высрал, игнорируя все аргументы, которые я написал выше). Поэтому повторюсь. Во-первых, Elixir даёт изоляцию ошибок. Во-вторых, Elixir тупо удобнее чем PHP/Python/Ruby/JS по тулингу, либам, перформансу. В-третьих, Elixir тупо лаконичнее и менее требовательный к инфраструктуре чем Go. В-четвёртых, в Elixir очень много изкоробки того, что в Go люди пишут сами.
> CRDT с eventual consistency
> Raft/Zab/Multipaxos с Master-Slave
> инструмент, который претендует на роль оркестратора
> не способен организовывать хранение данных
Причём тут распределённые алгоритмы вообще? Причём тут embedded базы данных? Что ты вообще блять несёшь? Elixir это не база данных, Elixir это блять не кубернетес, Elixir это не либа с распределёнными алгоритмами, Elixir это не средство для линеаризации эвентов. Elixir это язык программирования и фреймворк для написания распределённых программ. Он решает за тебя самые банальные задачи распределённого мира и предлагает уже готовую акторную модель. То есть Elixir даёт тебе нормальные и настоящие акторы, мониторинг ресурсов, изоляцию ошибок, супервайзинг, поведения для стейтмашин и акторов, эффективный интерконнект, ультрапростой RPC, посылку любых данных между нодами (да, даже блять замыкания можно посылать), пакование любых структур в байты, систему релизов для hot-reload, телеметрию и трейсинг, тулинг для отладки систем во время их исполнения, причём всех видов: от трейсинга и профайлеров до точечного инспекта состояния и ещё тонны других полезных вещей. И это всё ахуенно высокого качества, best practice решения, обкатанные в продах в разных конфигурациях и в ебейших топологиях. А теперь посмотри что есть в Go. Ты бы на Go эти вещи писал с нуля или подключал как либы от васянов, у каждого из которых своё мнение на счёт того как должны выглядеть распределённые алгоритмы.
Я на Elixir могу просто подключиться в прод реплом, дёрнуть :sys.get_state над нужным процессом и найти причину ошибки. Я могу в Elixir без какой-либо телеметрии просто увидеть какой процесс у меня памяти много жрёт. Меня просто не ебут эти проблемы, я не сижу с потным ебалом и не обкладываюсь логами, try/catch-ами и прочим defensive калом, пытаясь предсказать где что-то может наебнуться. Я просто знаю, что я могу подключиться к ноде и найти любую ошибку в моменте.
>>474752
"Есть три буддийских способа смотреть телевизор. В сущности, это один и тот же способ, но на разных стадиях тренировки он выглядит по-разному. Сначала ты смотришь телевизор с выключенным звуком. Примерно полчаса в день, свои любимые передачи. Когда возникает мысль, что по телевизору говорят что-то важное и интересное, ты осознаешь ее в момент появления и тем самым нейтрализуешь. Сперва ты будешь срываться и включать звук, но постепенно привыкнешь. Главное, чтобы не возникало чувства вины, когда не можешь удержаться. Сначала так со всеми бывает, даже с ламами. Потом ты начинаешь смотреть телевизор с включенным звуком, но отключенным изображением. И наконец, начинаешь смотреть выключенный телевизор. Это, собственно, главная техника, а первые две – подготовительные. Смотришь все программы новостей, но телевизор не включаешь. Очень важно, чтобы при этом была прямая спина, а руки лучше всего складывать на животе – правая ладонь снизу, левая сверху. Это для мужчин, а для женщин наоборот. И ни на секунду не отвлекаться. Если так смотреть телевизор десять лет подряд хотя бы по часу в день, можно понять природу телевидения. Да и всего остального тоже"
>я действительно читаю данные в два раза быстрее редиса. Линейная зависимость.
"Есть три буддийских способа смотреть телевизор. В сущности, это один и тот же способ, но на разных стадиях тренировки он выглядит по-разному. Сначала ты смотришь телевизор с выключенным звуком. Примерно полчаса в день, свои любимые передачи. Когда возникает мысль, что по телевизору говорят что-то важное и интересное, ты осознаешь ее в момент появления и тем самым нейтрализуешь. Сперва ты будешь срываться и включать звук, но постепенно привыкнешь. Главное, чтобы не возникало чувства вины, когда не можешь удержаться. Сначала так со всеми бывает, даже с ламами. Потом ты начинаешь смотреть телевизор с включенным звуком, но отключенным изображением. И наконец, начинаешь смотреть выключенный телевизор. Это, собственно, главная техника, а первые две – подготовительные. Смотришь все программы новостей, но телевизор не включаешь. Очень важно, чтобы при этом была прямая спина, а руки лучше всего складывать на животе – правая ладонь снизу, левая сверху. Это для мужчин, а для женщин наоборот. И ни на секунду не отвлекаться. Если так смотреть телевизор десять лет подряд хотя бы по часу в день, можно понять природу телевидения. Да и всего остального тоже"
>>476344
Репликация (не обязательно гео) синхроная с acks=all, родной. Если у меня не придёт ack от реплики, то запись сфейлится и надо будет её ретрайнуть.
> георепликация у неё только асинхронная
Репликация (не обязательно гео) синхроная с acks=all, родной. Если у меня не придёт ack от реплики, то запись сфейлится и надо будет её ретрайнуть.
>>476438
Никогда не было мысли "эх, щас бы нам сюда изоляцию ошибок". Оч слабый аргумент, как бы требующий встать на твоё место и увидеть твой конкретный проект, в котором вот никакак именно без этой изоляции ошибок нельзя было жить.
Сейчас в тред позову толпу индусов, которые тебе возразят.
В третьих, Elixir не умеет половины того, что умеет Go, потому обвязки вокруг Elixir придётся сделать не меньше — для того, что реализовать функции, которые Elixir сделать не смог (по крайней мере с адекватной производительностью). И, вполне возможно, эта обвязка вокруг Elixir будет написана на Go, внезапно. Вот тебе и "лаконичнее".
Elixir — это специализированный инструмент, который почти нихуя не умеет, но какие-то распределённые программы на нём пишутся. Правда, какие программы — не совсем понятно. WhatsApp, Discord — да, и то частично, Elixir там малую долю кода составляет.
Вычисления — нет. ML — нет. Персистентность или хотя бы её координация — не более, чем в том же питоне.
Akka даёт настоящие акторы, с персистентностью. Акторы в BEAM нужны потому, что там больш нихуя и нет, это в принципе единственный доступный способ организации программ. Актор BEAM — это замыкание-класс, то есть функция с своими изолированными локальными данными. И то же самое можно сделать во многих других ЯП, но не получить той же степени изоляции. Потому на самом деле речь не про акторы, а про изоляцию.
Потребность в локальном интерконнекте и координации возникает для того, чтобы обратить последствия этой самой изоляции. Вот удалённая координация — это уже интереснее, это мало кто делал. Но она работает только для этой конкретно модели акторов BEAM, акторы калибра Akka на ней нельзя координировать.
Вот как раз если бы можно было хорошо работать с хранилищами байтов, то в BEAM была бы своя локальная СУБД аля LevelDB. Но "любые струкутры" — это на самом деле очень узкое множество. А как предложишь между ЯП структуры передавать? Protobuf это умеет, но с Protobuf внезапно получается, что уже и не "любые структуры" можно передать.
И в сухом остатке получается, что вся эта сериализация нужна только как внутренний инструмент BEAM.
Нет никакой магии в сием инструменте. Даже с BEAM ею не все пользуются, потому что можно неиллюзорно выстрелить себе в ногу. По той же причине я никогда не верил в хуету про hot-reload и возобновляемые исключения — они требуют ебливой тщательной обработки, и намного проще её не делать.
И я ещё раз повторюсь, что сервисы за пределами BEAM легче обновлять не становится.
Я не знаком с набором инструментов в BEAM, но должен заметить, что в том же Linux есть инструменты на базе eBPF (bcc, bpftrace, tracee), которыми возможно анализировать процесс почти без вмешательства в его работу. Я подозреваю, что это сложнее, чем исследование родных сущностей BEAM (точно сложнее, чем анализ работы родным отладчиком).
Подразумевается, что у тебя всё реализовано на Elixir. Но выше ты соглашаешься, что Elixir не может быть в каждой бочке затычкой. Ну хорошо, состояние программы на Elixir ты посмотришь — а со всей остальной системой это как согласовывать? Для отладки и мониторинга гетерогенных систем нужны Dapper, Zipkin, и прочая хуета, которая, очевидно, не входит в состав BEAM.
>Во-первых, Elixir даёт изоляцию ошибок.
Никогда не было мысли "эх, щас бы нам сюда изоляцию ошибок". Оч слабый аргумент, как бы требующий встать на твоё место и увидеть твой конкретный проект, в котором вот никакак именно без этой изоляции ошибок нельзя было жить.
>Elixir тупо удобнее чем PHP/Python/Ruby/JS по тулингу, либам, перформансу
Сейчас в тред позову толпу индусов, которые тебе возразят.
>В-третьих, Elixir тупо лаконичнее и менее требовательный к инфраструктуре чем Go.
В третьих, Elixir не умеет половины того, что умеет Go, потому обвязки вокруг Elixir придётся сделать не меньше — для того, что реализовать функции, которые Elixir сделать не смог (по крайней мере с адекватной производительностью). И, вполне возможно, эта обвязка вокруг Elixir будет написана на Go, внезапно. Вот тебе и "лаконичнее".
>Elixir это не база данных, Elixir это блять не кубернетес, Elixir это не либа с распределёнными алгоритмами, Elixir это не средство для линеаризации эвентов. Elixir это язык программирования и фреймворк для написания распределённых программ.
Elixir — это специализированный инструмент, который почти нихуя не умеет, но какие-то распределённые программы на нём пишутся. Правда, какие программы — не совсем понятно. WhatsApp, Discord — да, и то частично, Elixir там малую долю кода составляет.
Вычисления — нет. ML — нет. Персистентность или хотя бы её координация — не более, чем в том же питоне.
>Elixir даёт тебе нормальные и настоящие акторы, мониторинг ресурсов, изоляцию ошибок, супервайзинг
Akka даёт настоящие акторы, с персистентностью. Акторы в BEAM нужны потому, что там больш нихуя и нет, это в принципе единственный доступный способ организации программ. Актор BEAM — это замыкание-класс, то есть функция с своими изолированными локальными данными. И то же самое можно сделать во многих других ЯП, но не получить той же степени изоляции. Потому на самом деле речь не про акторы, а про изоляцию.
Потребность в локальном интерконнекте и координации возникает для того, чтобы обратить последствия этой самой изоляции. Вот удалённая координация — это уже интереснее, это мало кто делал. Но она работает только для этой конкретно модели акторов BEAM, акторы калибра Akka на ней нельзя координировать.
>посылку любых данных между нодами (да, даже блять замыкания можно посылать), пакование любых структур в байты
Вот как раз если бы можно было хорошо работать с хранилищами байтов, то в BEAM была бы своя локальная СУБД аля LevelDB. Но "любые струкутры" — это на самом деле очень узкое множество. А как предложишь между ЯП структуры передавать? Protobuf это умеет, но с Protobuf внезапно получается, что уже и не "любые структуры" можно передать.
И в сухом остатке получается, что вся эта сериализация нужна только как внутренний инструмент BEAM.
>систему релизов для hot-reload
Нет никакой магии в сием инструменте. Даже с BEAM ею не все пользуются, потому что можно неиллюзорно выстрелить себе в ногу. По той же причине я никогда не верил в хуету про hot-reload и возобновляемые исключения — они требуют ебливой тщательной обработки, и намного проще её не делать.
И я ещё раз повторюсь, что сервисы за пределами BEAM легче обновлять не становится.
>телеметрию и трейсинг, тулинг для отладки систем во время их исполнения, причём всех видов: от трейсинга и профайлеров до точечного инспекта состояния и ещё тонны других полезных вещей.
Я не знаком с набором инструментов в BEAM, но должен заметить, что в том же Linux есть инструменты на базе eBPF (bcc, bpftrace, tracee), которыми возможно анализировать процесс почти без вмешательства в его работу. Я подозреваю, что это сложнее, чем исследование родных сущностей BEAM (точно сложнее, чем анализ работы родным отладчиком).
>Я на Elixir могу просто подключиться в прод реплом, дёрнуть :sys.get_state над нужным процессом и найти причину ошибки. Я могу в Elixir без какой-либо телеметрии просто увидеть какой процесс у меня памяти много жрёт.
Подразумевается, что у тебя всё реализовано на Elixir. Но выше ты соглашаешься, что Elixir не может быть в каждой бочке затычкой. Ну хорошо, состояние программы на Elixir ты посмотришь — а со всей остальной системой это как согласовывать? Для отладки и мониторинга гетерогенных систем нужны Dapper, Zipkin, и прочая хуета, которая, очевидно, не входит в состав BEAM.
>>476438
Никогда не было мысли "эх, щас бы нам сюда изоляцию ошибок". Оч слабый аргумент, как бы требующий встать на твоё место и увидеть твой конкретный проект, в котором вот никакак именно без этой изоляции ошибок нельзя было жить.
Сейчас в тред позову толпу индусов, которые тебе возразят.
В третьих, Elixir не умеет половины того, что умеет Go, потому обвязки вокруг Elixir придётся сделать не меньше — для того, что реализовать функции, которые Elixir сделать не смог (по крайней мере с адекватной производительностью). И, вполне возможно, эта обвязка вокруг Elixir будет написана на Go, внезапно. Вот тебе и "лаконичнее".
Elixir — это специализированный инструмент, который почти нихуя не умеет, но какие-то распределённые программы на нём пишутся. Правда, какие программы — не совсем понятно. WhatsApp, Discord — да, и то частично, Elixir там малую долю кода составляет.
Вычисления — нет. ML — нет. Персистентность или хотя бы её координация — не более, чем в том же питоне.
Akka даёт настоящие акторы, с персистентностью. Акторы в BEAM нужны потому, что там больш нихуя и нет, это в принципе единственный доступный способ организации программ. Актор BEAM — это замыкание-класс, то есть функция с своими изолированными локальными данными. И то же самое можно сделать во многих других ЯП, но не получить той же степени изоляции. Потому на самом деле речь не про акторы, а про изоляцию.
Потребность в локальном интерконнекте и координации возникает для того, чтобы обратить последствия этой самой изоляции. Вот удалённая координация — это уже интереснее, это мало кто делал. Но она работает только для этой конкретно модели акторов BEAM, акторы калибра Akka на ней нельзя координировать.
Вот как раз если бы можно было хорошо работать с хранилищами байтов, то в BEAM была бы своя локальная СУБД аля LevelDB. Но "любые струкутры" — это на самом деле очень узкое множество. А как предложишь между ЯП структуры передавать? Protobuf это умеет, но с Protobuf внезапно получается, что уже и не "любые структуры" можно передать.
И в сухом остатке получается, что вся эта сериализация нужна только как внутренний инструмент BEAM.
Нет никакой магии в сием инструменте. Даже с BEAM ею не все пользуются, потому что можно неиллюзорно выстрелить себе в ногу. По той же причине я никогда не верил в хуету про hot-reload и возобновляемые исключения — они требуют ебливой тщательной обработки, и намного проще её не делать.
И я ещё раз повторюсь, что сервисы за пределами BEAM легче обновлять не становится.
Я не знаком с набором инструментов в BEAM, но должен заметить, что в том же Linux есть инструменты на базе eBPF (bcc, bpftrace, tracee), которыми возможно анализировать процесс почти без вмешательства в его работу. Я подозреваю, что это сложнее, чем исследование родных сущностей BEAM (точно сложнее, чем анализ работы родным отладчиком).
Подразумевается, что у тебя всё реализовано на Elixir. Но выше ты соглашаешься, что Elixir не может быть в каждой бочке затычкой. Ну хорошо, состояние программы на Elixir ты посмотришь — а со всей остальной системой это как согласовывать? Для отладки и мониторинга гетерогенных систем нужны Dapper, Zipkin, и прочая хуета, которая, очевидно, не входит в состав BEAM.
>Во-первых, Elixir даёт изоляцию ошибок.
Никогда не было мысли "эх, щас бы нам сюда изоляцию ошибок". Оч слабый аргумент, как бы требующий встать на твоё место и увидеть твой конкретный проект, в котором вот никакак именно без этой изоляции ошибок нельзя было жить.
>Elixir тупо удобнее чем PHP/Python/Ruby/JS по тулингу, либам, перформансу
Сейчас в тред позову толпу индусов, которые тебе возразят.
>В-третьих, Elixir тупо лаконичнее и менее требовательный к инфраструктуре чем Go.
В третьих, Elixir не умеет половины того, что умеет Go, потому обвязки вокруг Elixir придётся сделать не меньше — для того, что реализовать функции, которые Elixir сделать не смог (по крайней мере с адекватной производительностью). И, вполне возможно, эта обвязка вокруг Elixir будет написана на Go, внезапно. Вот тебе и "лаконичнее".
>Elixir это не база данных, Elixir это блять не кубернетес, Elixir это не либа с распределёнными алгоритмами, Elixir это не средство для линеаризации эвентов. Elixir это язык программирования и фреймворк для написания распределённых программ.
Elixir — это специализированный инструмент, который почти нихуя не умеет, но какие-то распределённые программы на нём пишутся. Правда, какие программы — не совсем понятно. WhatsApp, Discord — да, и то частично, Elixir там малую долю кода составляет.
Вычисления — нет. ML — нет. Персистентность или хотя бы её координация — не более, чем в том же питоне.
>Elixir даёт тебе нормальные и настоящие акторы, мониторинг ресурсов, изоляцию ошибок, супервайзинг
Akka даёт настоящие акторы, с персистентностью. Акторы в BEAM нужны потому, что там больш нихуя и нет, это в принципе единственный доступный способ организации программ. Актор BEAM — это замыкание-класс, то есть функция с своими изолированными локальными данными. И то же самое можно сделать во многих других ЯП, но не получить той же степени изоляции. Потому на самом деле речь не про акторы, а про изоляцию.
Потребность в локальном интерконнекте и координации возникает для того, чтобы обратить последствия этой самой изоляции. Вот удалённая координация — это уже интереснее, это мало кто делал. Но она работает только для этой конкретно модели акторов BEAM, акторы калибра Akka на ней нельзя координировать.
>посылку любых данных между нодами (да, даже блять замыкания можно посылать), пакование любых структур в байты
Вот как раз если бы можно было хорошо работать с хранилищами байтов, то в BEAM была бы своя локальная СУБД аля LevelDB. Но "любые струкутры" — это на самом деле очень узкое множество. А как предложишь между ЯП структуры передавать? Protobuf это умеет, но с Protobuf внезапно получается, что уже и не "любые структуры" можно передать.
И в сухом остатке получается, что вся эта сериализация нужна только как внутренний инструмент BEAM.
>систему релизов для hot-reload
Нет никакой магии в сием инструменте. Даже с BEAM ею не все пользуются, потому что можно неиллюзорно выстрелить себе в ногу. По той же причине я никогда не верил в хуету про hot-reload и возобновляемые исключения — они требуют ебливой тщательной обработки, и намного проще её не делать.
И я ещё раз повторюсь, что сервисы за пределами BEAM легче обновлять не становится.
>телеметрию и трейсинг, тулинг для отладки систем во время их исполнения, причём всех видов: от трейсинга и профайлеров до точечного инспекта состояния и ещё тонны других полезных вещей.
Я не знаком с набором инструментов в BEAM, но должен заметить, что в том же Linux есть инструменты на базе eBPF (bcc, bpftrace, tracee), которыми возможно анализировать процесс почти без вмешательства в его работу. Я подозреваю, что это сложнее, чем исследование родных сущностей BEAM (точно сложнее, чем анализ работы родным отладчиком).
>Я на Elixir могу просто подключиться в прод реплом, дёрнуть :sys.get_state над нужным процессом и найти причину ошибки. Я могу в Elixir без какой-либо телеметрии просто увидеть какой процесс у меня памяти много жрёт.
Подразумевается, что у тебя всё реализовано на Elixir. Но выше ты соглашаешься, что Elixir не может быть в каждой бочке затычкой. Ну хорошо, состояние программы на Elixir ты посмотришь — а со всей остальной системой это как согласовывать? Для отладки и мониторинга гетерогенных систем нужны Dapper, Zipkin, и прочая хуета, которая, очевидно, не входит в состав BEAM.
>>476532
Ну вот ты try/catch пишешь? Вот это тоже изоляция ошибок. Только в Elixir она сделана по-человечески: вокруг стейта, а не вокруг функций. Если у меня произойдёт исключение, которое я не знаю как обработать, у меня просто перезапустится кусочек состояния, а не весь контейнер/тред/что-то там ещё. Это разговор про то, что тебе не надо душиться и обрабатывать все ошибки, чтобы иметь хороший аптайм. Это разговор про деньги и про удобство. Я выше писал пример как это генерирует деньги, как аптайм генерирует деньги.
Ну я просто объективно прав. mix как тул это считай cargo, а это уже в разы сильнее чем python, php и js. У Elixir более взрослая экосистема, там нет тонн каловых либ от школьников, как в js и python, нет leftpad-ов, нет node-packages на гигабайты. Ну и Elixir удобнее чем Ruby в плане async и многопоточности.
Как же ты меня заебал с этой хуйнёй уёбище. Вот последний раз поясню. Elixir это не база данных, Elixir это не кубернетес, Elixir это не R, Elixir это не блять решение всех проблем. Elixir это язык, который предоставляет кучу фичей, описанных выше.
Твой поинт, что "если в системе есть база данных, то это не система написанная на Elixir" я услышал ещё в первый раз, и уже тогда разобрал что это бред какой-то. Но я могу повторить специально для тебя. Во-первых, покажи мне систему, где и база данных, и ML и вычисления (что такое вычисления) написаны на одном языке. А ты и не покажешь, потому что такую хуйню способны сделать только очень конченные ебланы. В реальном мире ML-ем, написанием баз данных и всем таким занимаются разные люди. Во-вторых, и это очень важный момент, а хули ты только на бд и сервисах останавливаешься. Вот у меня любая программа использует ядро (а в нём тоже могут быть ошибки), а оно запущено в гипервизоре каком-то (и в нём тоже могут быть ошибки), а гипервизор и ядро используют какие-то драйвера, а драйвера обращаются к железкам у которых есть свой микрокод со своими микропроцессорами специализированным (и там тоже могут быть ошибки). А, ну и напомни, на каком языке обычно реализованы компилятор и/или виртуалка. Получается, что любая программа, даже ебучий print("hello world"), состоит на 99.9% из C. По-твоему, чтобы быть языком для написания распределённых систем, надо начинать с того что на языке можно писать микрокод и драйвера? Нет, потому что такое мог бы придумать только конченный еблан. Ну и в-третьих, если считать количество кода не как конченный еблан, а как адекватный человек, всё-таки в репках Discord и WhatsApp заметно большая часть кода написана на Elixir (и соответственно Erlang).
И вот теперь самый главный момент, который тебе нужно уяснить. Язык для отказоустойчивых распределённых систем, это не язык на котором можно написать свою базу данных. Если бы моя отказоустойчивая система всегда начиналась с написания своей бд, у меня всегда получался бы забагованный кал, на любом языке, потому что написать бд это пиздец как не просто. Поэтому и любой адекватный проект работает так: мы берём готовые сервисы, которые не нужно дебажить (за всю свою карьеру я дебажил БД всего лишь 1 раз, и тогда это оказался не баг), и их используем, а всю логику взаимодействия этих сервисов мы пишем на <язык нейм>. Так работает любой прагматичный проект, ведь не брать готовые решения в 2025-ом году просто невозможно, команда, у которой есть специализация в написании ядра, базы данных, консенсус протоколов, и веба, будет стоить столько денег, что проще вообще нихуя не писать изначально, а вероятность завершить проект за хотя бы 10 лет будет очень мала. В любом случае, адекватные команды поступают так: они берут готовые сервисы и либы, и потом пишут код, который с ними взаимодействует. Получается что 99% кода, который пишут люди, это код взаимодействия сервисов. Каждый коннект к сервису это состояние, каждый сервис живёт на отдельной машине, каждый сервис ожидает определённую нагрузку. Поэтому да, я не реализую сервисы на Elixir (и слава богу), я беру Elixir и им оборачиваю интерфейс в сервис, и оно для меня, внутри моей системы, превращается в актор оборачивающий устройство, и всё.
Теперь про твой аргумент "раз есть сторонние сервисы, тогда фичи Elixir не работают". Так они и никогда не работали на сторонний код, ты не можешь Elixir-ом дебажить ебаное ядро. Но зато ты можешь Elixir-ом инакпсулировать работу с сервисом с Protobuf апи в процесс (или в группу процессов), и у тебя будет максимально реалистичная работа с этим сервисом, с таймаутами, с проверкой жив он или нет, и возможно с рестартами (но так не делают обычно). Я буду внутри своего кода посылать сервису сообщения, буду от него их ждать, мониторить жив ли он, как обычный процесс или нода.
Поэтому вывод, и я больше на твой тупой кал отвечать не буду. Ты считаешь, что "язык для написания распределённых систем — это язык на котором можно написать базу данных, ML, супервизор и всё такое". Я считаю, что "язык для написания распределённых систем — это язык на котором можно максимально эффективно подключаться к разным интерфейсам, сервисам, базам данных и их соединять друг с другом так, чтобы это всё было интроспективно и ошибки были изолированы". Грубо говоря, Elixir это язык логической оркестрации сервисов, а это считай 99.9% задач на всём бэкенде
> Никогда не было мысли "эх, щас бы нам сюда изоляцию ошибок"
Ну вот ты try/catch пишешь? Вот это тоже изоляция ошибок. Только в Elixir она сделана по-человечески: вокруг стейта, а не вокруг функций. Если у меня произойдёт исключение, которое я не знаю как обработать, у меня просто перезапустится кусочек состояния, а не весь контейнер/тред/что-то там ещё. Это разговор про то, что тебе не надо душиться и обрабатывать все ошибки, чтобы иметь хороший аптайм. Это разговор про деньги и про удобство. Я выше писал пример как это генерирует деньги, как аптайм генерирует деньги.
> Сейчас в тред позову толпу индусов, которые тебе возразят.
Ну я просто объективно прав. mix как тул это считай cargo, а это уже в разы сильнее чем python, php и js. У Elixir более взрослая экосистема, там нет тонн каловых либ от школьников, как в js и python, нет leftpad-ов, нет node-packages на гигабайты. Ну и Elixir удобнее чем Ruby в плане async и многопоточности.
> вполне возможно, эта обвязка вокруг Elixir будет написана на Go, внезапно. Вот тебе и "лаконичнее".
> WhatsApp, Discord — да, и то частично
> Вычисления — нет. ML — нет. Персистентность или хотя бы её координация — не более, чем в том же питоне.
Как же ты меня заебал с этой хуйнёй уёбище. Вот последний раз поясню. Elixir это не база данных, Elixir это не кубернетес, Elixir это не R, Elixir это не блять решение всех проблем. Elixir это язык, который предоставляет кучу фичей, описанных выше.
Твой поинт, что "если в системе есть база данных, то это не система написанная на Elixir" я услышал ещё в первый раз, и уже тогда разобрал что это бред какой-то. Но я могу повторить специально для тебя. Во-первых, покажи мне систему, где и база данных, и ML и вычисления (что такое вычисления) написаны на одном языке. А ты и не покажешь, потому что такую хуйню способны сделать только очень конченные ебланы. В реальном мире ML-ем, написанием баз данных и всем таким занимаются разные люди. Во-вторых, и это очень важный момент, а хули ты только на бд и сервисах останавливаешься. Вот у меня любая программа использует ядро (а в нём тоже могут быть ошибки), а оно запущено в гипервизоре каком-то (и в нём тоже могут быть ошибки), а гипервизор и ядро используют какие-то драйвера, а драйвера обращаются к железкам у которых есть свой микрокод со своими микропроцессорами специализированным (и там тоже могут быть ошибки). А, ну и напомни, на каком языке обычно реализованы компилятор и/или виртуалка. Получается, что любая программа, даже ебучий print("hello world"), состоит на 99.9% из C. По-твоему, чтобы быть языком для написания распределённых систем, надо начинать с того что на языке можно писать микрокод и драйвера? Нет, потому что такое мог бы придумать только конченный еблан. Ну и в-третьих, если считать количество кода не как конченный еблан, а как адекватный человек, всё-таки в репках Discord и WhatsApp заметно большая часть кода написана на Elixir (и соответственно Erlang).
И вот теперь самый главный момент, который тебе нужно уяснить. Язык для отказоустойчивых распределённых систем, это не язык на котором можно написать свою базу данных. Если бы моя отказоустойчивая система всегда начиналась с написания своей бд, у меня всегда получался бы забагованный кал, на любом языке, потому что написать бд это пиздец как не просто. Поэтому и любой адекватный проект работает так: мы берём готовые сервисы, которые не нужно дебажить (за всю свою карьеру я дебажил БД всего лишь 1 раз, и тогда это оказался не баг), и их используем, а всю логику взаимодействия этих сервисов мы пишем на <язык нейм>. Так работает любой прагматичный проект, ведь не брать готовые решения в 2025-ом году просто невозможно, команда, у которой есть специализация в написании ядра, базы данных, консенсус протоколов, и веба, будет стоить столько денег, что проще вообще нихуя не писать изначально, а вероятность завершить проект за хотя бы 10 лет будет очень мала. В любом случае, адекватные команды поступают так: они берут готовые сервисы и либы, и потом пишут код, который с ними взаимодействует. Получается что 99% кода, который пишут люди, это код взаимодействия сервисов. Каждый коннект к сервису это состояние, каждый сервис живёт на отдельной машине, каждый сервис ожидает определённую нагрузку. Поэтому да, я не реализую сервисы на Elixir (и слава богу), я беру Elixir и им оборачиваю интерфейс в сервис, и оно для меня, внутри моей системы, превращается в актор оборачивающий устройство, и всё.
Теперь про твой аргумент "раз есть сторонние сервисы, тогда фичи Elixir не работают". Так они и никогда не работали на сторонний код, ты не можешь Elixir-ом дебажить ебаное ядро. Но зато ты можешь Elixir-ом инакпсулировать работу с сервисом с Protobuf апи в процесс (или в группу процессов), и у тебя будет максимально реалистичная работа с этим сервисом, с таймаутами, с проверкой жив он или нет, и возможно с рестартами (но так не делают обычно). Я буду внутри своего кода посылать сервису сообщения, буду от него их ждать, мониторить жив ли он, как обычный процесс или нода.
Поэтому вывод, и я больше на твой тупой кал отвечать не буду. Ты считаешь, что "язык для написания распределённых систем — это язык на котором можно написать базу данных, ML, супервизор и всё такое". Я считаю, что "язык для написания распределённых систем — это язык на котором можно максимально эффективно подключаться к разным интерфейсам, сервисам, базам данных и их соединять друг с другом так, чтобы это всё было интроспективно и ошибки были изолированы". Грубо говоря, Elixir это язык логической оркестрации сервисов, а это считай 99.9% задач на всём бэкенде
>>476532
Ну вот ты try/catch пишешь? Вот это тоже изоляция ошибок. Только в Elixir она сделана по-человечески: вокруг стейта, а не вокруг функций. Если у меня произойдёт исключение, которое я не знаю как обработать, у меня просто перезапустится кусочек состояния, а не весь контейнер/тред/что-то там ещё. Это разговор про то, что тебе не надо душиться и обрабатывать все ошибки, чтобы иметь хороший аптайм. Это разговор про деньги и про удобство. Я выше писал пример как это генерирует деньги, как аптайм генерирует деньги.
Ну я просто объективно прав. mix как тул это считай cargo, а это уже в разы сильнее чем python, php и js. У Elixir более взрослая экосистема, там нет тонн каловых либ от школьников, как в js и python, нет leftpad-ов, нет node-packages на гигабайты. Ну и Elixir удобнее чем Ruby в плане async и многопоточности.
Как же ты меня заебал с этой хуйнёй уёбище. Вот последний раз поясню. Elixir это не база данных, Elixir это не кубернетес, Elixir это не R, Elixir это не блять решение всех проблем. Elixir это язык, который предоставляет кучу фичей, описанных выше.
Твой поинт, что "если в системе есть база данных, то это не система написанная на Elixir" я услышал ещё в первый раз, и уже тогда разобрал что это бред какой-то. Но я могу повторить специально для тебя. Во-первых, покажи мне систему, где и база данных, и ML и вычисления (что такое вычисления) написаны на одном языке. А ты и не покажешь, потому что такую хуйню способны сделать только очень конченные ебланы. В реальном мире ML-ем, написанием баз данных и всем таким занимаются разные люди. Во-вторых, и это очень важный момент, а хули ты только на бд и сервисах останавливаешься. Вот у меня любая программа использует ядро (а в нём тоже могут быть ошибки), а оно запущено в гипервизоре каком-то (и в нём тоже могут быть ошибки), а гипервизор и ядро используют какие-то драйвера, а драйвера обращаются к железкам у которых есть свой микрокод со своими микропроцессорами специализированным (и там тоже могут быть ошибки). А, ну и напомни, на каком языке обычно реализованы компилятор и/или виртуалка. Получается, что любая программа, даже ебучий print("hello world"), состоит на 99.9% из C. По-твоему, чтобы быть языком для написания распределённых систем, надо начинать с того что на языке можно писать микрокод и драйвера? Нет, потому что такое мог бы придумать только конченный еблан. Ну и в-третьих, если считать количество кода не как конченный еблан, а как адекватный человек, всё-таки в репках Discord и WhatsApp заметно большая часть кода написана на Elixir (и соответственно Erlang).
И вот теперь самый главный момент, который тебе нужно уяснить. Язык для отказоустойчивых распределённых систем, это не язык на котором можно написать свою базу данных. Если бы моя отказоустойчивая система всегда начиналась с написания своей бд, у меня всегда получался бы забагованный кал, на любом языке, потому что написать бд это пиздец как не просто. Поэтому и любой адекватный проект работает так: мы берём готовые сервисы, которые не нужно дебажить (за всю свою карьеру я дебажил БД всего лишь 1 раз, и тогда это оказался не баг), и их используем, а всю логику взаимодействия этих сервисов мы пишем на <язык нейм>. Так работает любой прагматичный проект, ведь не брать готовые решения в 2025-ом году просто невозможно, команда, у которой есть специализация в написании ядра, базы данных, консенсус протоколов, и веба, будет стоить столько денег, что проще вообще нихуя не писать изначально, а вероятность завершить проект за хотя бы 10 лет будет очень мала. В любом случае, адекватные команды поступают так: они берут готовые сервисы и либы, и потом пишут код, который с ними взаимодействует. Получается что 99% кода, который пишут люди, это код взаимодействия сервисов. Каждый коннект к сервису это состояние, каждый сервис живёт на отдельной машине, каждый сервис ожидает определённую нагрузку. Поэтому да, я не реализую сервисы на Elixir (и слава богу), я беру Elixir и им оборачиваю интерфейс в сервис, и оно для меня, внутри моей системы, превращается в актор оборачивающий устройство, и всё.
Теперь про твой аргумент "раз есть сторонние сервисы, тогда фичи Elixir не работают". Так они и никогда не работали на сторонний код, ты не можешь Elixir-ом дебажить ебаное ядро. Но зато ты можешь Elixir-ом инакпсулировать работу с сервисом с Protobuf апи в процесс (или в группу процессов), и у тебя будет максимально реалистичная работа с этим сервисом, с таймаутами, с проверкой жив он или нет, и возможно с рестартами (но так не делают обычно). Я буду внутри своего кода посылать сервису сообщения, буду от него их ждать, мониторить жив ли он, как обычный процесс или нода.
Поэтому вывод, и я больше на твой тупой кал отвечать не буду. Ты считаешь, что "язык для написания распределённых систем — это язык на котором можно написать базу данных, ML, супервизор и всё такое". Я считаю, что "язык для написания распределённых систем — это язык на котором можно максимально эффективно подключаться к разным интерфейсам, сервисам, базам данных и их соединять друг с другом так, чтобы это всё было интроспективно и ошибки были изолированы". Грубо говоря, Elixir это язык логической оркестрации сервисов, а это считай 99.9% задач на всём бэкенде
> Никогда не было мысли "эх, щас бы нам сюда изоляцию ошибок"
Ну вот ты try/catch пишешь? Вот это тоже изоляция ошибок. Только в Elixir она сделана по-человечески: вокруг стейта, а не вокруг функций. Если у меня произойдёт исключение, которое я не знаю как обработать, у меня просто перезапустится кусочек состояния, а не весь контейнер/тред/что-то там ещё. Это разговор про то, что тебе не надо душиться и обрабатывать все ошибки, чтобы иметь хороший аптайм. Это разговор про деньги и про удобство. Я выше писал пример как это генерирует деньги, как аптайм генерирует деньги.
> Сейчас в тред позову толпу индусов, которые тебе возразят.
Ну я просто объективно прав. mix как тул это считай cargo, а это уже в разы сильнее чем python, php и js. У Elixir более взрослая экосистема, там нет тонн каловых либ от школьников, как в js и python, нет leftpad-ов, нет node-packages на гигабайты. Ну и Elixir удобнее чем Ruby в плане async и многопоточности.
> вполне возможно, эта обвязка вокруг Elixir будет написана на Go, внезапно. Вот тебе и "лаконичнее".
> WhatsApp, Discord — да, и то частично
> Вычисления — нет. ML — нет. Персистентность или хотя бы её координация — не более, чем в том же питоне.
Как же ты меня заебал с этой хуйнёй уёбище. Вот последний раз поясню. Elixir это не база данных, Elixir это не кубернетес, Elixir это не R, Elixir это не блять решение всех проблем. Elixir это язык, который предоставляет кучу фичей, описанных выше.
Твой поинт, что "если в системе есть база данных, то это не система написанная на Elixir" я услышал ещё в первый раз, и уже тогда разобрал что это бред какой-то. Но я могу повторить специально для тебя. Во-первых, покажи мне систему, где и база данных, и ML и вычисления (что такое вычисления) написаны на одном языке. А ты и не покажешь, потому что такую хуйню способны сделать только очень конченные ебланы. В реальном мире ML-ем, написанием баз данных и всем таким занимаются разные люди. Во-вторых, и это очень важный момент, а хули ты только на бд и сервисах останавливаешься. Вот у меня любая программа использует ядро (а в нём тоже могут быть ошибки), а оно запущено в гипервизоре каком-то (и в нём тоже могут быть ошибки), а гипервизор и ядро используют какие-то драйвера, а драйвера обращаются к железкам у которых есть свой микрокод со своими микропроцессорами специализированным (и там тоже могут быть ошибки). А, ну и напомни, на каком языке обычно реализованы компилятор и/или виртуалка. Получается, что любая программа, даже ебучий print("hello world"), состоит на 99.9% из C. По-твоему, чтобы быть языком для написания распределённых систем, надо начинать с того что на языке можно писать микрокод и драйвера? Нет, потому что такое мог бы придумать только конченный еблан. Ну и в-третьих, если считать количество кода не как конченный еблан, а как адекватный человек, всё-таки в репках Discord и WhatsApp заметно большая часть кода написана на Elixir (и соответственно Erlang).
И вот теперь самый главный момент, который тебе нужно уяснить. Язык для отказоустойчивых распределённых систем, это не язык на котором можно написать свою базу данных. Если бы моя отказоустойчивая система всегда начиналась с написания своей бд, у меня всегда получался бы забагованный кал, на любом языке, потому что написать бд это пиздец как не просто. Поэтому и любой адекватный проект работает так: мы берём готовые сервисы, которые не нужно дебажить (за всю свою карьеру я дебажил БД всего лишь 1 раз, и тогда это оказался не баг), и их используем, а всю логику взаимодействия этих сервисов мы пишем на <язык нейм>. Так работает любой прагматичный проект, ведь не брать готовые решения в 2025-ом году просто невозможно, команда, у которой есть специализация в написании ядра, базы данных, консенсус протоколов, и веба, будет стоить столько денег, что проще вообще нихуя не писать изначально, а вероятность завершить проект за хотя бы 10 лет будет очень мала. В любом случае, адекватные команды поступают так: они берут готовые сервисы и либы, и потом пишут код, который с ними взаимодействует. Получается что 99% кода, который пишут люди, это код взаимодействия сервисов. Каждый коннект к сервису это состояние, каждый сервис живёт на отдельной машине, каждый сервис ожидает определённую нагрузку. Поэтому да, я не реализую сервисы на Elixir (и слава богу), я беру Elixir и им оборачиваю интерфейс в сервис, и оно для меня, внутри моей системы, превращается в актор оборачивающий устройство, и всё.
Теперь про твой аргумент "раз есть сторонние сервисы, тогда фичи Elixir не работают". Так они и никогда не работали на сторонний код, ты не можешь Elixir-ом дебажить ебаное ядро. Но зато ты можешь Elixir-ом инакпсулировать работу с сервисом с Protobuf апи в процесс (или в группу процессов), и у тебя будет максимально реалистичная работа с этим сервисом, с таймаутами, с проверкой жив он или нет, и возможно с рестартами (но так не делают обычно). Я буду внутри своего кода посылать сервису сообщения, буду от него их ждать, мониторить жив ли он, как обычный процесс или нода.
Поэтому вывод, и я больше на твой тупой кал отвечать не буду. Ты считаешь, что "язык для написания распределённых систем — это язык на котором можно написать базу данных, ML, супервизор и всё такое". Я считаю, что "язык для написания распределённых систем — это язык на котором можно максимально эффективно подключаться к разным интерфейсам, сервисам, базам данных и их соединять друг с другом так, чтобы это всё было интроспективно и ошибки были изолированы". Грубо говоря, Elixir это язык логической оркестрации сервисов, а это считай 99.9% задач на всём бэкенде
>>476443
Даже если ты хуйнёшь acks=all на продьюсерах и настроишь кластер из трёх брокеров брокеры как
min.insync.replicas=2
unclean.leader.election=false
log.flush.interval.ms=0
то ты всё равно не сможешь защититься от split-brain, когда у кафки старый мастер отвалился, а потом переподключился и испортил логи (два мастера неизбежно испортят логи. Даже с min.insync.replicas=3 ты не защитишься от этого, потому что к ебаной кафке распределённость прикручена сбоку, зато с min.insync.replicas=3 у тебя продьюсеры будут регулярно отваливаться, потому что минимальные затупы реплики будут останавливать кластер. Вот Zookeeper и KRaft, которые метаданные организуют, от такой проблемы страдать не будут, потому что у них есть эпохи и старый мастер никогда не запишет в кворум с новой эпохой.
Это мы сейчас разговаривали только про консистентность — при указанных мной настройках на георепликации Kafka будет работать настолько медленно, что проще выкинуть её нахуй и взять что-то более адаптированное под георепликацию. Потому чисто практически считается, что Kafka георепликацию не поддерживает, то есть, никто не пытается её использовать в таком режиме, потому что это бессмысленно.
>Репликация (не обязательно гео) синхроная с acks=all, родной. Если у меня не придёт ack от реплики, то запись сфейлится и надо будет её ретрайнуть.
Даже если ты хуйнёшь acks=all на продьюсерах и настроишь кластер из трёх брокеров брокеры как
min.insync.replicas=2
unclean.leader.election=false
log.flush.interval.ms=0
то ты всё равно не сможешь защититься от split-brain, когда у кафки старый мастер отвалился, а потом переподключился и испортил логи (два мастера неизбежно испортят логи. Даже с min.insync.replicas=3 ты не защитишься от этого, потому что к ебаной кафке распределённость прикручена сбоку, зато с min.insync.replicas=3 у тебя продьюсеры будут регулярно отваливаться, потому что минимальные затупы реплики будут останавливать кластер. Вот Zookeeper и KRaft, которые метаданные организуют, от такой проблемы страдать не будут, потому что у них есть эпохи и старый мастер никогда не запишет в кворум с новой эпохой.
Это мы сейчас разговаривали только про консистентность — при указанных мной настройках на георепликации Kafka будет работать настолько медленно, что проще выкинуть её нахуй и взять что-то более адаптированное под георепликацию. Потому чисто практически считается, что Kafka георепликацию не поддерживает, то есть, никто не пытается её использовать в таком режиме, потому что это бессмысленно.
>>476020
Что ты несешь, больной дегенерат? Запись на диск это бесплатная вещь? Синхронизация журнала это бесплатная вещь?
Когда кластер разделяется, даун. Например когда в нескольких регионах кластер, один регион отвалился полностью - у тебя либо неконсистентность данных, либо полный запрет на запись.
АХАХХАХАХАХА, боже, да ты же ебанутый нахуй!
Можешь не спорит, это реальность. И падение кафки будут, если обеспечивать консистентность, а твой говноредис с постгресом это отсталый кал.
Не собираюсь я палить говноедам топовые технологии. Ты должен жить на уровне отсталого животного, это твоя реальность.
> Это эффективно. От этого растёт латенси на запись, но общий throughput не меняется. Единственная экстра операция, которая происходит с acks=all это то что реплики отсылают ack тоже, а это считай бесплатная вещь в кластере кафки.
Что ты несешь, больной дегенерат? Запись на диск это бесплатная вещь? Синхронизация журнала это бесплатная вещь?
> Какого нахуй сетевого раздела. Я тебя сейчас один вещь скажу, ты только не обижайся, но кафка реплицируется нормально даже когда реплики в разных датацентрах.
Когда кластер разделяется, даун. Например когда в нескольких регионах кластер, один регион отвалился полностью - у тебя либо неконсистентность данных, либо полный запрет на запись.
> IPS
> IP адресов
АХАХХАХАХАХА, боже, да ты же ебанутый нахуй!
> Я спорю с хуйнёй написанной вот тут
Можешь не спорит, это реальность. И падение кафки будут, если обеспечивать консистентность, а твой говноредис с постгресом это отсталый кал.
> И я всё ещё жду, когда ты мне бенчмарк покажешь.
Не собираюсь я палить говноедам топовые технологии. Ты должен жить на уровне отсталого животного, это твоя реальность.
>>476702
Я пропустил слово в прошлом посте — это слово было Lisp. В Lisp это давно было, но больше такой хуйней никто не страдал. Это были не try-catch, это были хитрожопые варианты супервизии одной функции над другой с выбором разных стратегий retry/continue/fail, и retry/fail мало отличалось от Erlang, за исключением одного — в Erlang есть строгая изоляция и локальное состояние строго сливается в помойку. Хотя, в принципе, при retry/fail Lisp делал то же самое, но функция имеет доступ к глобальному состоянию, потому по умолчанию может накуралесить больше, чем в Erlang. Вот и вся разница.
Или ты думал, что гениальный Erlang из нихуя создали? На тот момент Lisp был второй по известности ЯП.
Если у тебя по-настоящему возникнет исключение, где-нибудь внутри BEAM или просто затронет фундаментальные конфигурационные структуры твоей программы в результате кривого последнего hot-reload, то тут тебе ничего не поможет. Простые ограниченные ошибки даже через сраный try-catch другие ЯП умеют обрабатывать, хотя я пишу на C/C++ и яростно пизжу по рукам всех, кто тянет в проект исключения, потому что явная передача и обработка ошибок в стиле Go работает намного лучше (неспроста она так реализована в Go).
У меня есть подозрение, что тебя ранее в карьере покусали какие-нибудь рубисты, которые с выпуском последнего релиза уронили сервер со стэктрейсом. У меня самого питон основной инструмент, и я его, сука. ненавижу, потому что он может совершенно внезапно высрать неизвестные науке типы исключений из либы, которая используется либой, которая используется либой, которая используется либой. Даже банальный HTTPSConnection имеет иерархию слоёв реализации в виде HTTPSConnection => io.BufferedReader/io.BufferedWriter => ssl.SSLSocket => socket.socket — и у каждого из них своё множество исключений, из-за чего в питоне почти нереальна структурированная обработка исключений с гарантиями. Даже если вы всё-всё вытестировали, все самые нереальные редчайшие ошибки сгенерировали через тот же eBPF — завтра выйдет новая версия библиотек, которая поменяет типы или обработку исключений, и у вас всё разлезется нахуй. Из-за чего я, опять же, в своём питоновом коде стараюсь передавать ошибки статусом наверх.
В своё время Гвидо и ко сами охуевали от проблемы, потому что сделали итераторы-генераторы-асинки на служебных исключениях (для остановки), а потом долго чесали репу по поводу того, как отличить служебное исключение от неслужебного, когда пользователю нужно перехватить ошибку, но не перехватывать служебный сигнал.
Справедливости ради, современные питоновые сервера запускаются многопроцессово через какие-нибудь gunicorn/uvicorn/daphne/hyperconn (десятки их), где весь нелокальный контекст держится в Redis/Memcached, потому остановка-запуск-перезагрузка происходит легко и непринуждённо, как в BEAM — не хватает только координации из коробки.
К Cargo та же самая претензия — там нихуя нет, а нет софта — нет проблем. В лучшем случае в cargo кладут тонкую прокладку и привязывают к внешней системе пакетирования-сборки, вроде vcpkg. Когда же у тебя появляется несколько рантаймов, несколько репозиториев, в том числе локальных своих, связи с другими ЯП, то вся "взрослость" куда-то исчезает.
>Ну вот ты try/catch пишешь? Вот это тоже изоляция ошибок. Только в Elixir она сделана по-человечески: вокруг стейта, а не вокруг функций.
Я пропустил слово в прошлом посте — это слово было Lisp. В Lisp это давно было, но больше такой хуйней никто не страдал. Это были не try-catch, это были хитрожопые варианты супервизии одной функции над другой с выбором разных стратегий retry/continue/fail, и retry/fail мало отличалось от Erlang, за исключением одного — в Erlang есть строгая изоляция и локальное состояние строго сливается в помойку. Хотя, в принципе, при retry/fail Lisp делал то же самое, но функция имеет доступ к глобальному состоянию, потому по умолчанию может накуралесить больше, чем в Erlang. Вот и вся разница.
Или ты думал, что гениальный Erlang из нихуя создали? На тот момент Lisp был второй по известности ЯП.
>Если у меня произойдёт исключение, которое я не знаю как обработать, у меня просто перезапустится кусочек состояния, а не весь контейнер/тред/что-то там ещё.
Если у тебя по-настоящему возникнет исключение, где-нибудь внутри BEAM или просто затронет фундаментальные конфигурационные структуры твоей программы в результате кривого последнего hot-reload, то тут тебе ничего не поможет. Простые ограниченные ошибки даже через сраный try-catch другие ЯП умеют обрабатывать, хотя я пишу на C/C++ и яростно пизжу по рукам всех, кто тянет в проект исключения, потому что явная передача и обработка ошибок в стиле Go работает намного лучше (неспроста она так реализована в Go).
У меня есть подозрение, что тебя ранее в карьере покусали какие-нибудь рубисты, которые с выпуском последнего релиза уронили сервер со стэктрейсом. У меня самого питон основной инструмент, и я его, сука. ненавижу, потому что он может совершенно внезапно высрать неизвестные науке типы исключений из либы, которая используется либой, которая используется либой, которая используется либой. Даже банальный HTTPSConnection имеет иерархию слоёв реализации в виде HTTPSConnection => io.BufferedReader/io.BufferedWriter => ssl.SSLSocket => socket.socket — и у каждого из них своё множество исключений, из-за чего в питоне почти нереальна структурированная обработка исключений с гарантиями. Даже если вы всё-всё вытестировали, все самые нереальные редчайшие ошибки сгенерировали через тот же eBPF — завтра выйдет новая версия библиотек, которая поменяет типы или обработку исключений, и у вас всё разлезется нахуй. Из-за чего я, опять же, в своём питоновом коде стараюсь передавать ошибки статусом наверх.
В своё время Гвидо и ко сами охуевали от проблемы, потому что сделали итераторы-генераторы-асинки на служебных исключениях (для остановки), а потом долго чесали репу по поводу того, как отличить служебное исключение от неслужебного, когда пользователю нужно перехватить ошибку, но не перехватывать служебный сигнал.
Справедливости ради, современные питоновые сервера запускаются многопроцессово через какие-нибудь gunicorn/uvicorn/daphne/hyperconn (десятки их), где весь нелокальный контекст держится в Redis/Memcached, потому остановка-запуск-перезагрузка происходит легко и непринуждённо, как в BEAM — не хватает только координации из коробки.
>mix как тул это считай cargo, а это уже в разы сильнее чем python, php и js. У Elixir более взрослая экосистема, там нет тонн каловых либ от школьников, как в js и python, нет leftpad-ов, нет node-packages на гигабайты.
К Cargo та же самая претензия — там нихуя нет, а нет софта — нет проблем. В лучшем случае в cargo кладут тонкую прокладку и привязывают к внешней системе пакетирования-сборки, вроде vcpkg. Когда же у тебя появляется несколько рантаймов, несколько репозиториев, в том числе локальных своих, связи с другими ЯП, то вся "взрослость" куда-то исчезает.
>>476702
Я пропустил слово в прошлом посте — это слово было Lisp. В Lisp это давно было, но больше такой хуйней никто не страдал. Это были не try-catch, это были хитрожопые варианты супервизии одной функции над другой с выбором разных стратегий retry/continue/fail, и retry/fail мало отличалось от Erlang, за исключением одного — в Erlang есть строгая изоляция и локальное состояние строго сливается в помойку. Хотя, в принципе, при retry/fail Lisp делал то же самое, но функция имеет доступ к глобальному состоянию, потому по умолчанию может накуралесить больше, чем в Erlang. Вот и вся разница.
Или ты думал, что гениальный Erlang из нихуя создали? На тот момент Lisp был второй по известности ЯП.
Если у тебя по-настоящему возникнет исключение, где-нибудь внутри BEAM или просто затронет фундаментальные конфигурационные структуры твоей программы в результате кривого последнего hot-reload, то тут тебе ничего не поможет. Простые ограниченные ошибки даже через сраный try-catch другие ЯП умеют обрабатывать, хотя я пишу на C/C++ и яростно пизжу по рукам всех, кто тянет в проект исключения, потому что явная передача и обработка ошибок в стиле Go работает намного лучше (неспроста она так реализована в Go).
У меня есть подозрение, что тебя ранее в карьере покусали какие-нибудь рубисты, которые с выпуском последнего релиза уронили сервер со стэктрейсом. У меня самого питон основной инструмент, и я его, сука. ненавижу, потому что он может совершенно внезапно высрать неизвестные науке типы исключений из либы, которая используется либой, которая используется либой, которая используется либой. Даже банальный HTTPSConnection имеет иерархию слоёв реализации в виде HTTPSConnection => io.BufferedReader/io.BufferedWriter => ssl.SSLSocket => socket.socket — и у каждого из них своё множество исключений, из-за чего в питоне почти нереальна структурированная обработка исключений с гарантиями. Даже если вы всё-всё вытестировали, все самые нереальные редчайшие ошибки сгенерировали через тот же eBPF — завтра выйдет новая версия библиотек, которая поменяет типы или обработку исключений, и у вас всё разлезется нахуй. Из-за чего я, опять же, в своём питоновом коде стараюсь передавать ошибки статусом наверх.
В своё время Гвидо и ко сами охуевали от проблемы, потому что сделали итераторы-генераторы-асинки на служебных исключениях (для остановки), а потом долго чесали репу по поводу того, как отличить служебное исключение от неслужебного, когда пользователю нужно перехватить ошибку, но не перехватывать служебный сигнал.
Справедливости ради, современные питоновые сервера запускаются многопроцессово через какие-нибудь gunicorn/uvicorn/daphne/hyperconn (десятки их), где весь нелокальный контекст держится в Redis/Memcached, потому остановка-запуск-перезагрузка происходит легко и непринуждённо, как в BEAM — не хватает только координации из коробки.
К Cargo та же самая претензия — там нихуя нет, а нет софта — нет проблем. В лучшем случае в cargo кладут тонкую прокладку и привязывают к внешней системе пакетирования-сборки, вроде vcpkg. Когда же у тебя появляется несколько рантаймов, несколько репозиториев, в том числе локальных своих, связи с другими ЯП, то вся "взрослость" куда-то исчезает.
>Ну вот ты try/catch пишешь? Вот это тоже изоляция ошибок. Только в Elixir она сделана по-человечески: вокруг стейта, а не вокруг функций.
Я пропустил слово в прошлом посте — это слово было Lisp. В Lisp это давно было, но больше такой хуйней никто не страдал. Это были не try-catch, это были хитрожопые варианты супервизии одной функции над другой с выбором разных стратегий retry/continue/fail, и retry/fail мало отличалось от Erlang, за исключением одного — в Erlang есть строгая изоляция и локальное состояние строго сливается в помойку. Хотя, в принципе, при retry/fail Lisp делал то же самое, но функция имеет доступ к глобальному состоянию, потому по умолчанию может накуралесить больше, чем в Erlang. Вот и вся разница.
Или ты думал, что гениальный Erlang из нихуя создали? На тот момент Lisp был второй по известности ЯП.
>Если у меня произойдёт исключение, которое я не знаю как обработать, у меня просто перезапустится кусочек состояния, а не весь контейнер/тред/что-то там ещё.
Если у тебя по-настоящему возникнет исключение, где-нибудь внутри BEAM или просто затронет фундаментальные конфигурационные структуры твоей программы в результате кривого последнего hot-reload, то тут тебе ничего не поможет. Простые ограниченные ошибки даже через сраный try-catch другие ЯП умеют обрабатывать, хотя я пишу на C/C++ и яростно пизжу по рукам всех, кто тянет в проект исключения, потому что явная передача и обработка ошибок в стиле Go работает намного лучше (неспроста она так реализована в Go).
У меня есть подозрение, что тебя ранее в карьере покусали какие-нибудь рубисты, которые с выпуском последнего релиза уронили сервер со стэктрейсом. У меня самого питон основной инструмент, и я его, сука. ненавижу, потому что он может совершенно внезапно высрать неизвестные науке типы исключений из либы, которая используется либой, которая используется либой, которая используется либой. Даже банальный HTTPSConnection имеет иерархию слоёв реализации в виде HTTPSConnection => io.BufferedReader/io.BufferedWriter => ssl.SSLSocket => socket.socket — и у каждого из них своё множество исключений, из-за чего в питоне почти нереальна структурированная обработка исключений с гарантиями. Даже если вы всё-всё вытестировали, все самые нереальные редчайшие ошибки сгенерировали через тот же eBPF — завтра выйдет новая версия библиотек, которая поменяет типы или обработку исключений, и у вас всё разлезется нахуй. Из-за чего я, опять же, в своём питоновом коде стараюсь передавать ошибки статусом наверх.
В своё время Гвидо и ко сами охуевали от проблемы, потому что сделали итераторы-генераторы-асинки на служебных исключениях (для остановки), а потом долго чесали репу по поводу того, как отличить служебное исключение от неслужебного, когда пользователю нужно перехватить ошибку, но не перехватывать служебный сигнал.
Справедливости ради, современные питоновые сервера запускаются многопроцессово через какие-нибудь gunicorn/uvicorn/daphne/hyperconn (десятки их), где весь нелокальный контекст держится в Redis/Memcached, потому остановка-запуск-перезагрузка происходит легко и непринуждённо, как в BEAM — не хватает только координации из коробки.
>mix как тул это считай cargo, а это уже в разы сильнее чем python, php и js. У Elixir более взрослая экосистема, там нет тонн каловых либ от школьников, как в js и python, нет leftpad-ов, нет node-packages на гигабайты.
К Cargo та же самая претензия — там нихуя нет, а нет софта — нет проблем. В лучшем случае в cargo кладут тонкую прокладку и привязывают к внешней системе пакетирования-сборки, вроде vcpkg. Когда же у тебя появляется несколько рантаймов, несколько репозиториев, в том числе локальных своих, связи с другими ЯП, то вся "взрослость" куда-то исчезает.
>>476702
Если у тебя критические функции вне BEAM не работают, то похую, какой аптайм у BEAM. Ровно такая же претенизя у меня к микросервиснутым, у которых 99.999% аптайм сервисов, но индекса поднимаеются 8 часов после потери консенсуса (тру стори, у амазона недавно такое было). Ты привёл пример, где BEAM вытащил бизнес, но можно же привести пример, где утонула БД и вместе с ней критический кусок бизнеса, и там уже до пизды, какой аптайм BEAM. Вот у моего знакомого в трейдинге бизнес продаёт истории торгов, им только за это и платят, и если у них сломается доступ к БД, то твой BEAM уже ничем не поможет. На одной из моих прошлых работ 95% всей работы сервера сводилась к CRUD-ам. Сильно эти проектам поможет выживший BEAM?
Вычисления — стриминг видео, данных, вроде того же RocksDB. Ты можешь переписать RocksDB на эрланге и получить 1/50 производительности. Самое смешное то, что даже Python умеет в быструю переработку данных за счёт расишрений на C/C++. Да, можно доебаться, что это не один ЯП, но расширения питона пишутся специально для питона, это примерно как ETS в BEAM.
И по итогу мы имеем монстров вроде Flink, который выполняет логику десяти строчек на баше, но очен масштабируемым и отказоустойчивым способом. И на каждые новые десять строчек нужно писать новый проект Apache, вроде Pulsar, который как бы Kafka, но немножко не Kafka.
Чисто теоретически, да, Си в роли системного ЯП — это кусок говна. Но практика говорит, что мы не всемогущи и у нас не бесконечные ресурсы, потому приходится ограничиваться готовыми решениями. Я бы всё-таки совсетовал ограничиваться той областью, которую мы рассматриваем — бизнес-логику и кординацию.
Discord
🧩 Estimated Language Breakdown (Backend + Client combined):
Language Usage Area Estimate
JavaScript/TypeScriptElectron desktop app, web client, some backend APIs~30–40%
Rust High-performance backend services, media/voice stack~20%
Elixir Core backend services, chat/message delivery~15–20%
Go Infrastructure tooling, newer backend services~10%
C++ Voice engine, SFU, low-level media handling~5–10%
Python Some legacy tooling, possibly some bots/admin tasks~5%
Others Shell scripts, configs, internal DSLs, etc.~1–2%
WhatsApp
🧩 Estimated Language Breakdown:
Language Usage Area Estimate
Erlang Core messaging backend, signaling~30%
Java Android app~20%
Objective-C / Swift iOS app~15%
C++ Encryption, protocol handling, some backend parts~10–15%
JavaScript/React Web client~10%
Python / Bash Scripting, automation~3–5%
Hack / PHP If integrated with Meta infra~2–3%
Others Configs, YAML, internal tools~1–2%
Здесь не стоит сбрасывать со счетов клиентскую часть, потому что, например, логика групповых чатов в WhatsApp перенесена на клиент. Для решения подобных проблем с группами в Discord решили реализовывать тяжелую логику на Rust.
Использование RocksDB — это "написание своей БД" или нет? Чот я не видел в RocksDB поддержки корзины продуктов и двухфакторной авторизации.
Если у тебя нет готовой БД прямо выполняющую твою задачу, то, да, ты "пишешь свою БД" — вопрос лишь в том, из каких блоков. Даже если ты берёшь Oracle — это ещё нихуя не значит, что операции в твоей системе будут линеарезуемы, а выдаваемые по REST API снимки буду констистентны — ты сам должен эти свойства реализовать имеющимися в Oracle и интеграторе инструментами.
Никто не спорит, в 2025 году программировать не стало проще — просто готовых решений стало больше. И ChatGPT — это всего-лишь инструмент для нанизывания готовых кусков кода на шампур, не-готовые решения он не умеет выдавать.
Вот здесь я нихуя не понял, сорян. Может быть я слишком мало работал в проектах плана "ехал сервис через сервис", но у меня все разрабатываемые сервисы дохуя чего вычисляли (шифрование, кодировка, парсинг) и взаимодействовали с БД. На последнем проекте я даже, честно говоря, не знаю, с каким числом БД мой сервис взаимодействует, потому часть из них скрыта за чужими модулями, и не я архитектор/CTO всей этой хуйни. А вот своего состояния у этого сервиса как раз было очень мало — это относительно кратковременное соединение и немногочисленные кэши. Причём, соединение по большей части сторонний софт обрабатывал, для меня это просто пайп.
В чём здесь отличие Elixir от #{языкнейма}?
Забавное определение понятия "логическая оркестрация сервисов". То есть, большая часть оркестракции в виде запуска-перезапуска-обновления-конфигурации сервисов (Go, Rust, RDBMS, Message queue, Cache) и просто фоновых задач обслуживания (прописать DNS, сделать плановые бэкапы) — это "нелогическая оркестрация", а эфемерный координатор (то он есть, то его сразу нет) — это "логическая оркестрация".
>Это разговор про то, что тебе не надо душиться и обрабатывать все ошибки, чтобы иметь хороший аптайм. Это разговор про деньги и про удобство. Я выше писал пример как это генерирует деньги, как аптайм генерирует деньги.
Если у тебя критические функции вне BEAM не работают, то похую, какой аптайм у BEAM. Ровно такая же претенизя у меня к микросервиснутым, у которых 99.999% аптайм сервисов, но индекса поднимаеются 8 часов после потери консенсуса (тру стори, у амазона недавно такое было). Ты привёл пример, где BEAM вытащил бизнес, но можно же привести пример, где утонула БД и вместе с ней критический кусок бизнеса, и там уже до пизды, какой аптайм BEAM. Вот у моего знакомого в трейдинге бизнес продаёт истории торгов, им только за это и платят, и если у них сломается доступ к БД, то твой BEAM уже ничем не поможет. На одной из моих прошлых работ 95% всей работы сервера сводилась к CRUD-ам. Сильно эти проектам поможет выживший BEAM?
>покажи мне систему, где и база данных, и ML и вычисления (что такое вычисления) написаны на одном языке
Вычисления — стриминг видео, данных, вроде того же RocksDB. Ты можешь переписать RocksDB на эрланге и получить 1/50 производительности. Самое смешное то, что даже Python умеет в быструю переработку данных за счёт расишрений на C/C++. Да, можно доебаться, что это не один ЯП, но расширения питона пишутся специально для питона, это примерно как ETS в BEAM.
>В реальном мире ML-ем, написанием баз данных и всем таким занимаются разные люди
И по итогу мы имеем монстров вроде Flink, который выполняет логику десяти строчек на баше, но очен масштабируемым и отказоустойчивым способом. И на каждые новые десять строчек нужно писать новый проект Apache, вроде Pulsar, который как бы Kafka, но немножко не Kafka.
>А, ну и напомни, на каком языке обычно реализованы компилятор и/или виртуалка. Получается, что любая программа, даже ебучий print("hello world"), состоит на 99.9% из C. По-твоему, чтобы быть языком для написания распределённых систем, надо начинать с того что на языке можно писать микрокод и драйвера?
Чисто теоретически, да, Си в роли системного ЯП — это кусок говна. Но практика говорит, что мы не всемогущи и у нас не бесконечные ресурсы, потому приходится ограничиваться готовыми решениями. Я бы всё-таки совсетовал ограничиваться той областью, которую мы рассматриваем — бизнес-логику и кординацию.
>Ну и в-третьих, если считать количество кода не как конченный еблан, а как адекватный человек, всё-таки в репках Discord и WhatsApp заметно большая часть кода написана на Elixir (и соответственно Erlang).
Discord
🧩 Estimated Language Breakdown (Backend + Client combined):
Language Usage Area Estimate
JavaScript/TypeScriptElectron desktop app, web client, some backend APIs~30–40%
Rust High-performance backend services, media/voice stack~20%
Elixir Core backend services, chat/message delivery~15–20%
Go Infrastructure tooling, newer backend services~10%
C++ Voice engine, SFU, low-level media handling~5–10%
Python Some legacy tooling, possibly some bots/admin tasks~5%
Others Shell scripts, configs, internal DSLs, etc.~1–2%
🧩 Estimated Language Breakdown:
Language Usage Area Estimate
Erlang Core messaging backend, signaling~30%
Java Android app~20%
Objective-C / Swift iOS app~15%
C++ Encryption, protocol handling, some backend parts~10–15%
JavaScript/React Web client~10%
Python / Bash Scripting, automation~3–5%
Hack / PHP If integrated with Meta infra~2–3%
Others Configs, YAML, internal tools~1–2%
Здесь не стоит сбрасывать со счетов клиентскую часть, потому что, например, логика групповых чатов в WhatsApp перенесена на клиент. Для решения подобных проблем с группами в Discord решили реализовывать тяжелую логику на Rust.
>Если бы моя отказоустойчивая система всегда начиналась с написания своей бд
Использование RocksDB — это "написание своей БД" или нет? Чот я не видел в RocksDB поддержки корзины продуктов и двухфакторной авторизации.
Если у тебя нет готовой БД прямо выполняющую твою задачу, то, да, ты "пишешь свою БД" — вопрос лишь в том, из каких блоков. Даже если ты берёшь Oracle — это ещё нихуя не значит, что операции в твоей системе будут линеарезуемы, а выдаваемые по REST API снимки буду констистентны — ты сам должен эти свойства реализовать имеющимися в Oracle и интеграторе инструментами.
>Так работает любой прагматичный проект, ведь не брать готовые решения в 2025-ом году просто невозможно
Никто не спорит, в 2025 году программировать не стало проще — просто готовых решений стало больше. И ChatGPT — это всего-лишь инструмент для нанизывания готовых кусков кода на шампур, не-готовые решения он не умеет выдавать.
>Получается что 99% кода, который пишут люди, это код взаимодействия сервисов. Каждый коннект к сервису это состояние, каждый сервис живёт на отдельной машине, каждый сервис ожидает определённую нагрузку. Поэтому да, я не реализую сервисы на Elixir (и слава богу), я беру Elixir и им оборачиваю интерфейс в сервис, и оно для меня, внутри моей системы, превращается в актор оборачивающий устройство, и всё.
Вот здесь я нихуя не понял, сорян. Может быть я слишком мало работал в проектах плана "ехал сервис через сервис", но у меня все разрабатываемые сервисы дохуя чего вычисляли (шифрование, кодировка, парсинг) и взаимодействовали с БД. На последнем проекте я даже, честно говоря, не знаю, с каким числом БД мой сервис взаимодействует, потому часть из них скрыта за чужими модулями, и не я архитектор/CTO всей этой хуйни. А вот своего состояния у этого сервиса как раз было очень мало — это относительно кратковременное соединение и немногочисленные кэши. Причём, соединение по большей части сторонний софт обрабатывал, для меня это просто пайп.
>Но зато ты можешь Elixir-ом инакпсулировать работу с сервисом с Protobuf апи в процесс (или в группу процессов), и у тебя будет максимально реалистичная работа с этим сервисом, с таймаутами, с проверкой жив он или нет, и возможно с рестартами
В чём здесь отличие Elixir от #{языкнейма}?
>"язык для написания распределённых систем — это язык на котором можно максимально эффективно подключаться к разным интерфейсам, сервисам, базам данных и их соединять друг с другом так, чтобы это всё было интроспективно и ошибки были изолированы". Грубо говоря, Elixir это язык логической оркестрации сервисов, а это считай 99.9% задач на всём бэкенде
Забавное определение понятия "логическая оркестрация сервисов". То есть, большая часть оркестракции в виде запуска-перезапуска-обновления-конфигурации сервисов (Go, Rust, RDBMS, Message queue, Cache) и просто фоновых задач обслуживания (прописать DNS, сделать плановые бэкапы) — это "нелогическая оркестрация", а эфемерный координатор (то он есть, то его сразу нет) — это "логическая оркестрация".
>>476702
Если у тебя критические функции вне BEAM не работают, то похую, какой аптайм у BEAM. Ровно такая же претенизя у меня к микросервиснутым, у которых 99.999% аптайм сервисов, но индекса поднимаеются 8 часов после потери консенсуса (тру стори, у амазона недавно такое было). Ты привёл пример, где BEAM вытащил бизнес, но можно же привести пример, где утонула БД и вместе с ней критический кусок бизнеса, и там уже до пизды, какой аптайм BEAM. Вот у моего знакомого в трейдинге бизнес продаёт истории торгов, им только за это и платят, и если у них сломается доступ к БД, то твой BEAM уже ничем не поможет. На одной из моих прошлых работ 95% всей работы сервера сводилась к CRUD-ам. Сильно эти проектам поможет выживший BEAM?
Вычисления — стриминг видео, данных, вроде того же RocksDB. Ты можешь переписать RocksDB на эрланге и получить 1/50 производительности. Самое смешное то, что даже Python умеет в быструю переработку данных за счёт расишрений на C/C++. Да, можно доебаться, что это не один ЯП, но расширения питона пишутся специально для питона, это примерно как ETS в BEAM.
И по итогу мы имеем монстров вроде Flink, который выполняет логику десяти строчек на баше, но очен масштабируемым и отказоустойчивым способом. И на каждые новые десять строчек нужно писать новый проект Apache, вроде Pulsar, который как бы Kafka, но немножко не Kafka.
Чисто теоретически, да, Си в роли системного ЯП — это кусок говна. Но практика говорит, что мы не всемогущи и у нас не бесконечные ресурсы, потому приходится ограничиваться готовыми решениями. Я бы всё-таки совсетовал ограничиваться той областью, которую мы рассматриваем — бизнес-логику и кординацию.
Discord
🧩 Estimated Language Breakdown (Backend + Client combined):
Language Usage Area Estimate
JavaScript/TypeScriptElectron desktop app, web client, some backend APIs~30–40%
Rust High-performance backend services, media/voice stack~20%
Elixir Core backend services, chat/message delivery~15–20%
Go Infrastructure tooling, newer backend services~10%
C++ Voice engine, SFU, low-level media handling~5–10%
Python Some legacy tooling, possibly some bots/admin tasks~5%
Others Shell scripts, configs, internal DSLs, etc.~1–2%
WhatsApp
🧩 Estimated Language Breakdown:
Language Usage Area Estimate
Erlang Core messaging backend, signaling~30%
Java Android app~20%
Objective-C / Swift iOS app~15%
C++ Encryption, protocol handling, some backend parts~10–15%
JavaScript/React Web client~10%
Python / Bash Scripting, automation~3–5%
Hack / PHP If integrated with Meta infra~2–3%
Others Configs, YAML, internal tools~1–2%
Здесь не стоит сбрасывать со счетов клиентскую часть, потому что, например, логика групповых чатов в WhatsApp перенесена на клиент. Для решения подобных проблем с группами в Discord решили реализовывать тяжелую логику на Rust.
Использование RocksDB — это "написание своей БД" или нет? Чот я не видел в RocksDB поддержки корзины продуктов и двухфакторной авторизации.
Если у тебя нет готовой БД прямо выполняющую твою задачу, то, да, ты "пишешь свою БД" — вопрос лишь в том, из каких блоков. Даже если ты берёшь Oracle — это ещё нихуя не значит, что операции в твоей системе будут линеарезуемы, а выдаваемые по REST API снимки буду констистентны — ты сам должен эти свойства реализовать имеющимися в Oracle и интеграторе инструментами.
Никто не спорит, в 2025 году программировать не стало проще — просто готовых решений стало больше. И ChatGPT — это всего-лишь инструмент для нанизывания готовых кусков кода на шампур, не-готовые решения он не умеет выдавать.
Вот здесь я нихуя не понял, сорян. Может быть я слишком мало работал в проектах плана "ехал сервис через сервис", но у меня все разрабатываемые сервисы дохуя чего вычисляли (шифрование, кодировка, парсинг) и взаимодействовали с БД. На последнем проекте я даже, честно говоря, не знаю, с каким числом БД мой сервис взаимодействует, потому часть из них скрыта за чужими модулями, и не я архитектор/CTO всей этой хуйни. А вот своего состояния у этого сервиса как раз было очень мало — это относительно кратковременное соединение и немногочисленные кэши. Причём, соединение по большей части сторонний софт обрабатывал, для меня это просто пайп.
В чём здесь отличие Elixir от #{языкнейма}?
Забавное определение понятия "логическая оркестрация сервисов". То есть, большая часть оркестракции в виде запуска-перезапуска-обновления-конфигурации сервисов (Go, Rust, RDBMS, Message queue, Cache) и просто фоновых задач обслуживания (прописать DNS, сделать плановые бэкапы) — это "нелогическая оркестрация", а эфемерный координатор (то он есть, то его сразу нет) — это "логическая оркестрация".
>Это разговор про то, что тебе не надо душиться и обрабатывать все ошибки, чтобы иметь хороший аптайм. Это разговор про деньги и про удобство. Я выше писал пример как это генерирует деньги, как аптайм генерирует деньги.
Если у тебя критические функции вне BEAM не работают, то похую, какой аптайм у BEAM. Ровно такая же претенизя у меня к микросервиснутым, у которых 99.999% аптайм сервисов, но индекса поднимаеются 8 часов после потери консенсуса (тру стори, у амазона недавно такое было). Ты привёл пример, где BEAM вытащил бизнес, но можно же привести пример, где утонула БД и вместе с ней критический кусок бизнеса, и там уже до пизды, какой аптайм BEAM. Вот у моего знакомого в трейдинге бизнес продаёт истории торгов, им только за это и платят, и если у них сломается доступ к БД, то твой BEAM уже ничем не поможет. На одной из моих прошлых работ 95% всей работы сервера сводилась к CRUD-ам. Сильно эти проектам поможет выживший BEAM?
>покажи мне систему, где и база данных, и ML и вычисления (что такое вычисления) написаны на одном языке
Вычисления — стриминг видео, данных, вроде того же RocksDB. Ты можешь переписать RocksDB на эрланге и получить 1/50 производительности. Самое смешное то, что даже Python умеет в быструю переработку данных за счёт расишрений на C/C++. Да, можно доебаться, что это не один ЯП, но расширения питона пишутся специально для питона, это примерно как ETS в BEAM.
>В реальном мире ML-ем, написанием баз данных и всем таким занимаются разные люди
И по итогу мы имеем монстров вроде Flink, который выполняет логику десяти строчек на баше, но очен масштабируемым и отказоустойчивым способом. И на каждые новые десять строчек нужно писать новый проект Apache, вроде Pulsar, который как бы Kafka, но немножко не Kafka.
>А, ну и напомни, на каком языке обычно реализованы компилятор и/или виртуалка. Получается, что любая программа, даже ебучий print("hello world"), состоит на 99.9% из C. По-твоему, чтобы быть языком для написания распределённых систем, надо начинать с того что на языке можно писать микрокод и драйвера?
Чисто теоретически, да, Си в роли системного ЯП — это кусок говна. Но практика говорит, что мы не всемогущи и у нас не бесконечные ресурсы, потому приходится ограничиваться готовыми решениями. Я бы всё-таки совсетовал ограничиваться той областью, которую мы рассматриваем — бизнес-логику и кординацию.
>Ну и в-третьих, если считать количество кода не как конченный еблан, а как адекватный человек, всё-таки в репках Discord и WhatsApp заметно большая часть кода написана на Elixir (и соответственно Erlang).
Discord
🧩 Estimated Language Breakdown (Backend + Client combined):
Language Usage Area Estimate
JavaScript/TypeScriptElectron desktop app, web client, some backend APIs~30–40%
Rust High-performance backend services, media/voice stack~20%
Elixir Core backend services, chat/message delivery~15–20%
Go Infrastructure tooling, newer backend services~10%
C++ Voice engine, SFU, low-level media handling~5–10%
Python Some legacy tooling, possibly some bots/admin tasks~5%
Others Shell scripts, configs, internal DSLs, etc.~1–2%
🧩 Estimated Language Breakdown:
Language Usage Area Estimate
Erlang Core messaging backend, signaling~30%
Java Android app~20%
Objective-C / Swift iOS app~15%
C++ Encryption, protocol handling, some backend parts~10–15%
JavaScript/React Web client~10%
Python / Bash Scripting, automation~3–5%
Hack / PHP If integrated with Meta infra~2–3%
Others Configs, YAML, internal tools~1–2%
Здесь не стоит сбрасывать со счетов клиентскую часть, потому что, например, логика групповых чатов в WhatsApp перенесена на клиент. Для решения подобных проблем с группами в Discord решили реализовывать тяжелую логику на Rust.
>Если бы моя отказоустойчивая система всегда начиналась с написания своей бд
Использование RocksDB — это "написание своей БД" или нет? Чот я не видел в RocksDB поддержки корзины продуктов и двухфакторной авторизации.
Если у тебя нет готовой БД прямо выполняющую твою задачу, то, да, ты "пишешь свою БД" — вопрос лишь в том, из каких блоков. Даже если ты берёшь Oracle — это ещё нихуя не значит, что операции в твоей системе будут линеарезуемы, а выдаваемые по REST API снимки буду констистентны — ты сам должен эти свойства реализовать имеющимися в Oracle и интеграторе инструментами.
>Так работает любой прагматичный проект, ведь не брать готовые решения в 2025-ом году просто невозможно
Никто не спорит, в 2025 году программировать не стало проще — просто готовых решений стало больше. И ChatGPT — это всего-лишь инструмент для нанизывания готовых кусков кода на шампур, не-готовые решения он не умеет выдавать.
>Получается что 99% кода, который пишут люди, это код взаимодействия сервисов. Каждый коннект к сервису это состояние, каждый сервис живёт на отдельной машине, каждый сервис ожидает определённую нагрузку. Поэтому да, я не реализую сервисы на Elixir (и слава богу), я беру Elixir и им оборачиваю интерфейс в сервис, и оно для меня, внутри моей системы, превращается в актор оборачивающий устройство, и всё.
Вот здесь я нихуя не понял, сорян. Может быть я слишком мало работал в проектах плана "ехал сервис через сервис", но у меня все разрабатываемые сервисы дохуя чего вычисляли (шифрование, кодировка, парсинг) и взаимодействовали с БД. На последнем проекте я даже, честно говоря, не знаю, с каким числом БД мой сервис взаимодействует, потому часть из них скрыта за чужими модулями, и не я архитектор/CTO всей этой хуйни. А вот своего состояния у этого сервиса как раз было очень мало — это относительно кратковременное соединение и немногочисленные кэши. Причём, соединение по большей части сторонний софт обрабатывал, для меня это просто пайп.
>Но зато ты можешь Elixir-ом инакпсулировать работу с сервисом с Protobuf апи в процесс (или в группу процессов), и у тебя будет максимально реалистичная работа с этим сервисом, с таймаутами, с проверкой жив он или нет, и возможно с рестартами
В чём здесь отличие Elixir от #{языкнейма}?
>"язык для написания распределённых систем — это язык на котором можно максимально эффективно подключаться к разным интерфейсам, сервисам, базам данных и их соединять друг с другом так, чтобы это всё было интроспективно и ошибки были изолированы". Грубо говоря, Elixir это язык логической оркестрации сервисов, а это считай 99.9% задач на всём бэкенде
Забавное определение понятия "логическая оркестрация сервисов". То есть, большая часть оркестракции в виде запуска-перезапуска-обновления-конфигурации сервисов (Go, Rust, RDBMS, Message queue, Cache) и просто фоновых задач обслуживания (прописать DNS, сделать плановые бэкапы) — это "нелогическая оркестрация", а эфемерный координатор (то он есть, то его сразу нет) — это "логическая оркестрация".
>>476862
Нахуй ты сюда скидываешь нейросгенерированный кал. Откуда нейронка знает блять какой код внутри Discord, он не опенсурсный, там закрытый код. Может лучше посмотришь на выступления разработчиков? Или на вакансии разрабов в Discord? Я-то знаю, что нейронка пиздит, ведь мой бывший коллега работал в Discord, и он рассказывал что основной язык в бэкенде Discord App это Elixir, а единственные другие два языка это C++ для кодеков и Rust для NIF-ок.
> 🧩 Estimated Language Breakdown (Backend + Client combined):
Нахуй ты сюда скидываешь нейросгенерированный кал. Откуда нейронка знает блять какой код внутри Discord, он не опенсурсный, там закрытый код. Может лучше посмотришь на выступления разработчиков? Или на вакансии разрабов в Discord? Я-то знаю, что нейронка пиздит, ведь мой бывший коллега работал в Discord, и он рассказывал что основной язык в бэкенде Discord App это Elixir, а единственные другие два языка это C++ для кодеков и Rust для NIF-ок.
>>476862
Я не понимаю хули ты к этому так приебался. Каждый ебаный день ты пишешь эту ебаную хуйню в чат. Ты ответь мне, у меня уже руки трясутся нахуй, ты мне, ебанутый, просто ответь. Тебе на Elixir кто-то мешает использовать embedded бд? Твою любимую RocksDB кто-то мешает использовать? Тебе кто-то мешает использовать отдельную бд на соседней машине? Тебе кто-то мешает написать на Elixir код, который будет рестартить тебе бд если она упадёт?
Нет, никто тебе не мешает. Ты можешь хоть левой, хоть правой, хоть в перчатках дрочить, но к Elixir это отношения не имеет. Это язык программирования, а не база данных, блять. Язык программирование решает проблему написания программ, а не супервайзинга сервисов, хранения данных и прочей хуйни. Всё. Ты на Elixir можешь написать любую распределённую бд, какую хочешь. Вон посмотри на CouchDB, на Riak, на Mnesia+Mria. Но ты можешь и не писать бд, а использовать готовую, ебанат ебанутый. Ты почитай что тебе люди пишут тут, бога ради. Хоть обдрочись на эти свои базы данных, только отъебись, ОТЪЕБИИИСЬ НАХУЙ уже от тредика со своей ебанутой хуйнёй какой-то
Каких расширений? Если ты про numpy, то у Elixir есть более Nx, компилирующийся в более современные бэкенды для тензорных перемножений. А для нейронок в Elixir есть Axon и Bumblebee. Если ты про вещи типа классов array, то в Elixir тоже можно писать NIF-ы. Например, вся крипта это один большой NIF в Elixir.
> утонула БД и вместе с ней критический кусок бизнеса
Я не понимаю хули ты к этому так приебался. Каждый ебаный день ты пишешь эту ебаную хуйню в чат. Ты ответь мне, у меня уже руки трясутся нахуй, ты мне, ебанутый, просто ответь. Тебе на Elixir кто-то мешает использовать embedded бд? Твою любимую RocksDB кто-то мешает использовать? Тебе кто-то мешает использовать отдельную бд на соседней машине? Тебе кто-то мешает написать на Elixir код, который будет рестартить тебе бд если она упадёт?
Нет, никто тебе не мешает. Ты можешь хоть левой, хоть правой, хоть в перчатках дрочить, но к Elixir это отношения не имеет. Это язык программирования, а не база данных, блять. Язык программирование решает проблему написания программ, а не супервайзинга сервисов, хранения данных и прочей хуйни. Всё. Ты на Elixir можешь написать любую распределённую бд, какую хочешь. Вон посмотри на CouchDB, на Riak, на Mnesia+Mria. Но ты можешь и не писать бд, а использовать готовую, ебанат ебанутый. Ты почитай что тебе люди пишут тут, бога ради. Хоть обдрочись на эти свои базы данных, только отъебись, ОТЪЕБИИИСЬ НАХУЙ уже от тредика со своей ебанутой хуйнёй какой-то
> Самое смешное то, что даже Python умеет в быструю переработку данных за счёт расишрений на C/C++.
Каких расширений? Если ты про numpy, то у Elixir есть более Nx, компилирующийся в более современные бэкенды для тензорных перемножений. А для нейронок в Elixir есть Axon и Bumblebee. Если ты про вещи типа классов array, то в Elixir тоже можно писать NIF-ы. Например, вся крипта это один большой NIF в Elixir.
512x512>>476949
Нейронка пиздит, а упоротый фанат эликсира, рассказывающий про выдуманного друга - нет.
Нейронка пиздит, а упоротый фанат эликсира, рассказывающий про выдуманного друга - нет.
>>477252
Так я и не прошу мне на слово верить, почитайте блоги дискорда, почитайте вакансии на какой стек там нанимают и в каком количестве. Если это пиздёж, то меня же очень легко поймать
Так я и не прошу мне на слово верить, почитайте блоги дискорда, почитайте вакансии на какой стек там нанимают и в каком количестве. Если это пиздёж, то меня же очень легко поймать
>>477331
Я посмотрел их блог и он какой-то - ни о чём. Например https://discord.com/blog/how-it-all-goes-live-an-overview-of-discords-streaming-technology вроде такая тема, кодирование видео, но вообще ни слова о том какой язык используется, просто набор общих слов. Или другой пример https://discord.com/blog/how-discord-moved-engineering-to-cloud-development-environments тоже в основном бла-бла, но тут хотя бы упоминаются языки которые они используют
и Эликсир особо не выделяется, просто один из языков.
Ну и в целом, блог это такая "ошибка выжившего". Никто не будет писать про то как мы взяли и успешно написали сервис по перекладыванию жсонов. Писать будут про какие-то сложные случаи, поэтому там фокус другой, а 99% каждодневной работы не попадает в блог.
По вакансиям тоже что-то не заметно, чтобы они там сильно Эликсирили, например:
https://discord.com/jobs/7978053002
Это бэкенд и высоконагруженный, эликсир вообще не упоминается.
https://discord.com/jobs/7990178002
Опять бэк, опять никакого эликсира.
https://discord.com/jobs/8015636002
Эликсира нет.
https://discord.com/jobs/7953473002
Наконец, хоть и как бонус, но эликсир упоминается.
В общем вообще нет ощущения, что они там только на эликсире и пишут.
Я посмотрел их блог и он какой-то - ни о чём. Например https://discord.com/blog/how-it-all-goes-live-an-overview-of-discords-streaming-technology вроде такая тема, кодирование видео, но вообще ни слова о том какой язык используется, просто набор общих слов. Или другой пример https://discord.com/blog/how-discord-moved-engineering-to-cloud-development-environments тоже в основном бла-бла, но тут хотя бы упоминаются языки которые они используют
>Our software development takes place in a polyglot mono-repo, where Python, Typescript, Rust, Elixir, and C/C++ are the most actively developed languages.
и Эликсир особо не выделяется, просто один из языков.
Ну и в целом, блог это такая "ошибка выжившего". Никто не будет писать про то как мы взяли и успешно написали сервис по перекладыванию жсонов. Писать будут про какие-то сложные случаи, поэтому там фокус другой, а 99% каждодневной работы не попадает в блог.
По вакансиям тоже что-то не заметно, чтобы они там сильно Эликсирили, например:
https://discord.com/jobs/7978053002
>Senior Software Engineer- Database Infrastructure
>Proficiency with at least one statically-typed programming language: e.g. Rust, Go, Java, C, C++
>Bonus Points: Experience with Rust
Это бэкенд и высоконагруженный, эликсир вообще не упоминается.
https://discord.com/jobs/7990178002
>Software Engineer, Safety Processing
>you will work on the core safety pipeline — ingesting signals, like user reports, and the processing of those signals through automated and manual means
>3+ years experience working on full-stack products or systems using Python + Flask or similar technologies
Опять бэк, опять никакого эликсира.
https://discord.com/jobs/8015636002
>Software Engineer, Traffic Infrastructure
Эликсира нет.
https://discord.com/jobs/7953473002
>Staff Software Engineer, Audio/Video Infrastructure
>Bonus Points: Experience with Elixir
Наконец, хоть и как бонус, но эликсир упоминается.
В общем вообще нет ощущения, что они там только на эликсире и пишут.
>>477331
Я посмотрел их блог и он какой-то - ни о чём. Например https://discord.com/blog/how-it-all-goes-live-an-overview-of-discords-streaming-technology вроде такая тема, кодирование видео, но вообще ни слова о том какой язык используется, просто набор общих слов. Или другой пример https://discord.com/blog/how-discord-moved-engineering-to-cloud-development-environments тоже в основном бла-бла, но тут хотя бы упоминаются языки которые они используют
и Эликсир особо не выделяется, просто один из языков.
Ну и в целом, блог это такая "ошибка выжившего". Никто не будет писать про то как мы взяли и успешно написали сервис по перекладыванию жсонов. Писать будут про какие-то сложные случаи, поэтому там фокус другой, а 99% каждодневной работы не попадает в блог.
По вакансиям тоже что-то не заметно, чтобы они там сильно Эликсирили, например:
https://discord.com/jobs/7978053002
Это бэкенд и высоконагруженный, эликсир вообще не упоминается.
https://discord.com/jobs/7990178002
Опять бэк, опять никакого эликсира.
https://discord.com/jobs/8015636002
Эликсира нет.
https://discord.com/jobs/7953473002
Наконец, хоть и как бонус, но эликсир упоминается.
В общем вообще нет ощущения, что они там только на эликсире и пишут.
Я посмотрел их блог и он какой-то - ни о чём. Например https://discord.com/blog/how-it-all-goes-live-an-overview-of-discords-streaming-technology вроде такая тема, кодирование видео, но вообще ни слова о том какой язык используется, просто набор общих слов. Или другой пример https://discord.com/blog/how-discord-moved-engineering-to-cloud-development-environments тоже в основном бла-бла, но тут хотя бы упоминаются языки которые они используют
>Our software development takes place in a polyglot mono-repo, where Python, Typescript, Rust, Elixir, and C/C++ are the most actively developed languages.
и Эликсир особо не выделяется, просто один из языков.
Ну и в целом, блог это такая "ошибка выжившего". Никто не будет писать про то как мы взяли и успешно написали сервис по перекладыванию жсонов. Писать будут про какие-то сложные случаи, поэтому там фокус другой, а 99% каждодневной работы не попадает в блог.
По вакансиям тоже что-то не заметно, чтобы они там сильно Эликсирили, например:
https://discord.com/jobs/7978053002
>Senior Software Engineer- Database Infrastructure
>Proficiency with at least one statically-typed programming language: e.g. Rust, Go, Java, C, C++
>Bonus Points: Experience with Rust
Это бэкенд и высоконагруженный, эликсир вообще не упоминается.
https://discord.com/jobs/7990178002
>Software Engineer, Safety Processing
>you will work on the core safety pipeline — ingesting signals, like user reports, and the processing of those signals through automated and manual means
>3+ years experience working on full-stack products or systems using Python + Flask or similar technologies
Опять бэк, опять никакого эликсира.
https://discord.com/jobs/8015636002
>Software Engineer, Traffic Infrastructure
Эликсира нет.
https://discord.com/jobs/7953473002
>Staff Software Engineer, Audio/Video Infrastructure
>Bonus Points: Experience with Elixir
Наконец, хоть и как бонус, но эликсир упоминается.
В общем вообще нет ощущения, что они там только на эликсире и пишут.
Еще вспомнилось из прошлых тредов: была такая компания Klarna. Активно писала на Erlang, на конференциях выступали. Но уже в прошлых тредах, у них была одна открытая вакансия на Erlang-е и десяток на Java. А сейчас вообще 0 на Erlang-е и одна
в общем, тоже что-то не срослось с Erlang-ом.
>PHP, JavaScript, Python or Ruby on Rails
в общем, тоже что-то не срослось с Erlang-ом.
>>477689
Да, Klarna пересели с Erlang. Как и банк Brex, вроде, пересел с Elixir. В целом основная претензия и у тех, и у этих была не к языку, а к тому что программистов сложно искать.
Да, Klarna пересели с Erlang. Как и банк Brex, вроде, пересел с Elixir. В целом основная претензия и у тех, и у этих была не к языку, а к тому что программистов сложно искать.
>>477683
Так это подтверждает мой поинт же.
Первая вакансия это про прокладку между БД и бэкендом. Вторая ваканския это про ультрамаленький сервис. Третья это DevOps. А четвертая это про основной функционал дискорда (войс чатики).
Я не говорил что там пишут всё на Elixir, я говорил что там Elixir это основной язык бэкенда, на котором пишут основную логику. Конечно, у них много языков и много разных внутренних сервисов, я с этим не спорил. Но основной функционал и самые первые версии дискорда — это Elixir
Так это подтверждает мой поинт же.
Первая вакансия это про прокладку между БД и бэкендом. Вторая ваканския это про ультрамаленький сервис. Третья это DevOps. А четвертая это про основной функционал дискорда (войс чатики).
Я не говорил что там пишут всё на Elixir, я говорил что там Elixir это основной язык бэкенда, на котором пишут основную логику. Конечно, у них много языков и много разных внутренних сервисов, я с этим не спорил. Но основной функционал и самые первые версии дискорда — это Elixir
>>478169
Вот, кстати, хороший пост с тем как они использовали Elixir:
https://elixir-lang.org/blog/2020/10/08/real-time-communication-at-scale-with-elixir-at-discord/
Получается, что я наебал, что Elixir был основным с первого дня, ведь у них ещё есть легаси монолит на питоне
Вот, кстати, хороший пост с тем как они использовали Elixir:
https://elixir-lang.org/blog/2020/10/08/real-time-communication-at-scale-with-elixir-at-discord/
Получается, что я наебал, что Elixir был основным с первого дня, ведь у них ещё есть легаси монолит на питоне
>>476843
Ответить нечего, говноед с говностеком?
>>476963
Ерланг это не язык программирования, это OTP и ноды которые работают в кластере. Как язык программирование это говно нахуй никому не нужен.
Если есть своя система консистентности с CRDT и отказоустойчивости в кластере через WAL, то ерланг становится избыточным - сообщения между нодами всегда будут доставлены, половина OTP идёт нахуй. Всё что остаётся у ерланга - BEAM и управление процессами в кластере, но нахуй это нужно, если отказоустойчивый кластер уже существует? Потреблять лишние ресурсы и терпеть проебы денег? Нет, ерланг идёт нахуй.
Ответить нечего, говноед с говностеком?
>>476963
>Elixir это отношения не имеет. Это язык программирования, а не база данных, блять. Язык программирование решает проблему написания программ
Ерланг это не язык программирования, это OTP и ноды которые работают в кластере. Как язык программирование это говно нахуй никому не нужен.
Если есть своя система консистентности с CRDT и отказоустойчивости в кластере через WAL, то ерланг становится избыточным - сообщения между нодами всегда будут доставлены, половина OTP идёт нахуй. Всё что остаётся у ерланга - BEAM и управление процессами в кластере, но нахуй это нужно, если отказоустойчивый кластер уже существует? Потреблять лишние ресурсы и терпеть проебы денег? Нет, ерланг идёт нахуй.
>Эликсир способен запускать мильоны процессов-акторов, работающих асинхронно, с различными приоритетами и всем таким. Эти процессы не делят память и общаются через пересылку сообщений.
Это любая ОС может делать сука гои ебаные
>>478357
В операционных системах процессы жрут сильно больше памяти, сильно дольше инициализируются, относительно сложно друг с другом взаимодействуют. Эти аргументы не только к Elixir применимы, но и ко всем другим языкам с гринтредами, CSP типа современной Java и Go. Но ещё что уникально для Elixir и Erlang это то что в них процессы взаимодействуют с процессами на других машинках так же, как и с процессами на одной
> Это любая ОС может делать
В операционных системах процессы жрут сильно больше памяти, сильно дольше инициализируются, относительно сложно друг с другом взаимодействуют. Эти аргументы не только к Elixir применимы, но и ко всем другим языкам с гринтредами, CSP типа современной Java и Go. Но ещё что уникально для Elixir и Erlang это то что в них процессы взаимодействуют с процессами на других машинках так же, как и с процессами на одной
>>478162
О чём собственно и тред. Платят выше рынка не просто так, поэтому если думаете поменять стек, то Elixir это отличный вариант
> программистов сложно искать
О чём собственно и тред. Платят выше рынка не просто так, поэтому если думаете поменять стек, то Elixir это отличный вариант
>>478171
Отлично. Открываем https://elixir-lang.org/cases.html и видим 16 кейсов, 5 из которых это веб на фениксе. Выше уже скинули истории как та же Кларна и прочие наевшись с Эрлангом и т.д. тупо заменили ее на обычные императивные языки, т.к. работать надо, а не фантазировать про "тысячи процессов и обмен сообщениями". По факту твои "тысячи процессов" и "устойчивость к падениям" заменили на докер и кубернетис, а "обмена сообщениями" на банальную кафку. Вместо малоизвестного языка на котором пишет полторы калеки под очень редкий юзкейз, люди просто взяли кубер, докер, кафку + россыпь из императивных языков уровня гошки, жабы и сишарпа и пилят себе проекты.
Ну а эликсирщики ловят те редкие вакансии, 99%, которых это переписывание интернет-магазинов с Ruby on Rails, да и те быстро закрываются фрилансерами из-за границы. Рынок эликсира настолько мал, что может потягаться с окамлом или хаскелом - выглядит прикольно, но нужно работу работать и деньги зарабатывать
>Получается, что я наебал, что Elixir был основным
Отлично. Открываем https://elixir-lang.org/cases.html и видим 16 кейсов, 5 из которых это веб на фениксе. Выше уже скинули истории как та же Кларна и прочие наевшись с Эрлангом и т.д. тупо заменили ее на обычные императивные языки, т.к. работать надо, а не фантазировать про "тысячи процессов и обмен сообщениями". По факту твои "тысячи процессов" и "устойчивость к падениям" заменили на докер и кубернетис, а "обмена сообщениями" на банальную кафку. Вместо малоизвестного языка на котором пишет полторы калеки под очень редкий юзкейз, люди просто взяли кубер, докер, кафку + россыпь из императивных языков уровня гошки, жабы и сишарпа и пилят себе проекты.
Ну а эликсирщики ловят те редкие вакансии, 99%, которых это переписывание интернет-магазинов с Ruby on Rails, да и те быстро закрываются фрилансерами из-за границы. Рынок эликсира настолько мал, что может потягаться с окамлом или хаскелом - выглядит прикольно, но нужно работу работать и деньги зарабатывать
>>479464
Да, это в шапке треда написано. Но это вообще не имеет отношения ни к найму, ни к работе. Искать работу на эликсире где 10 вакансий (условно) и 20 программистов так же сложно, как и на Java где 1000 вакансий и 2000 программистов, потому что важно не количество вакансий, а человек/место.
Почему ты вообще решил, что Elixir и Erlang должны заменять кубы и event log-и? Elixir и Erlang прекрасно с ними работают вместе и я не ебу зачем их заменять. Интерконнект в Elixir и Erlang, как и супервайзинг, решают вообще другие задачи.
Так, и? Я могу на каждый проект где Elixir на <языкнейм> заменили, привести в пример проект где заменили <языкнейм> на Elixir. Да, даже с Go на Elixir заменяют, даже с Java (я в таких работал дважды по полгода). И что?
Твои слова звучат страшно, но это всё FUD, и на деле проекты на Elixir выстреливают (Discord, WhatsApp и тонны других), разработчики находят работу за хорошую зп, люди пишут отказоустойчивые системы, язык развивается и заходит на новые ниши, проекты с Go переписываются на Elixir.
Ты что доказать-то пытаешься здесь? К чему ты всё это написал?
> Рынок эликсира настолько мал
Да, это в шапке треда написано. Но это вообще не имеет отношения ни к найму, ни к работе. Искать работу на эликсире где 10 вакансий (условно) и 20 программистов так же сложно, как и на Java где 1000 вакансий и 2000 программистов, потому что важно не количество вакансий, а человек/место.
> "тысячи процессов" и "устойчивость к падениям" заменили на докер и кубернетис
Почему ты вообще решил, что Elixir и Erlang должны заменять кубы и event log-и? Elixir и Erlang прекрасно с ними работают вместе и я не ебу зачем их заменять. Интерконнект в Elixir и Erlang, как и супервайзинг, решают вообще другие задачи.
> Вместо малоизвестного языка люди просто взяли россыпь из императивных языков уровня гошки
Так, и? Я могу на каждый проект где Elixir на <языкнейм> заменили, привести в пример проект где заменили <языкнейм> на Elixir. Да, даже с Go на Elixir заменяют, даже с Java (я в таких работал дважды по полгода). И что?
Твои слова звучат страшно, но это всё FUD, и на деле проекты на Elixir выстреливают (Discord, WhatsApp и тонны других), разработчики находят работу за хорошую зп, люди пишут отказоустойчивые системы, язык развивается и заходит на новые ниши, проекты с Go переписываются на Elixir.
Ты что доказать-то пытаешься здесь? К чему ты всё это написал?
>>479745
То, что такие малопопулярные языки как эрланг и эликсир это не для среднего ума и конкуренция там на порядок выше чем на гошке или жабе.
>Ты что доказать-то пытаешься здесь?
То, что такие малопопулярные языки как эрланг и эликсир это не для среднего ума и конкуренция там на порядок выше чем на гошке или жабе.
>>479745
Классика черипикинга от долбоёба
Не на эрланге. У него предел масштабируемости 50-200 нод, дальше это не работает, дальше любые глобалстейты пиздатенько так дают тебе в рот и заставляют городить ебанутую архитектуру.
А если вспомнить что переплачивать за кластер на ерланге придётся в 20 раз больше чем за кластер на другом языке.......
>>479758
Вообще-то как раз для среднего. Эрланг проектировался с рассчтётом на дебилов - летиткраш. Сам язык говорит как бы что ты ДЕБИЛ который обязательно положит систему
>на деле проекты на Elixir выстреливают (Discord, WhatsApp и тонны других)
Классика черипикинга от долбоёба
>люди пишут отказоустойчивые системы
Не на эрланге. У него предел масштабируемости 50-200 нод, дальше это не работает, дальше любые глобалстейты пиздатенько так дают тебе в рот и заставляют городить ебанутую архитектуру.
А если вспомнить что переплачивать за кластер на ерланге придётся в 20 раз больше чем за кластер на другом языке.......
>>479758
> это не для среднего ума
Вообще-то как раз для среднего. Эрланг проектировался с рассчтётом на дебилов - летиткраш. Сам язык говорит как бы что ты ДЕБИЛ который обязательно положит систему
>>479897
Советую почитать сколько нод, например, у WhatsApp, лол. Видать взломали Erlang, чтобы выйти за предел. Если тебе интересно посмотреть как это работает, и как работают необычные топологии в Erlang, я советую почитать про hidden ноды, отключение connect all и вещи типа empdless
Вот с этим, кстати, согласен. Elixir и Erlang снимают очень много головной боли по сравнению с другими языками. Их легко учить (Elixir, кстати, сильно проще учить чем Erlang), легко использовать и легко рефакторить программы на них
> У него предел масштабируемости 50-200 нод
Советую почитать сколько нод, например, у WhatsApp, лол. Видать взломали Erlang, чтобы выйти за предел. Если тебе интересно посмотреть как это работает, и как работают необычные топологии в Erlang, я советую почитать про hidden ноды, отключение connect all и вещи типа empdless
> Вообще-то как раз для среднего. Эрланг проектировался с рассчтётом на дебилов - летиткраш. Сам язык говорит как бы что ты ДЕБИЛ который обязательно положит систему
Вот с этим, кстати, согласен. Elixir и Erlang снимают очень много головной боли по сравнению с другими языками. Их легко учить (Elixir, кстати, сильно проще учить чем Erlang), легко использовать и легко рефакторить программы на них
>>479921
Достаточно сравнить RabbitMQ и Kafka. Эрланг позорно соснул даже у тормозной жабы.
Достаточно сравнить RabbitMQ и Kafka. Эрланг позорно соснул даже у тормозной жабы.
>>479921
Нормальной поддержки в IDE с рефакторингом, инспекциями, навигацией и т.д. до сих пор не завезли. А если учесть, что у них динамическая, но строгая типизация, то это вообще пиздец
>легко использовать и легко рефакторить программы на них
Нормальной поддержки в IDE с рефакторингом, инспекциями, навигацией и т.д. до сих пор не завезли. А если учесть, что у них динамическая, но строгая типизация, то это вообще пиздец
>>479921
Они на GO переезжают уже давно. Вангую там от эликсира чуть больше чем нихуя.
Это не снизит нагрузку при передачи глобалстейта.
Ерланг разрабатывался для коммуникаторов всяких, для связи, а не для приложений. И сейчас не существует человека/группы которые бы пофиксили BEAM и OTP чтобы ерланг открыл для себя новую нишу.
Это не плюс, потому что подобный подход порождает архитектуру которая в десятки раз медленнее других языков. Ерланг медленнее NodeJS в 10-50 раз, блядь.
Ты понимаешь че вообще происходит? Компании начинают проект с ерланга, смотрят тесты и нахуй выкидывают ерланг. Жизненный цикл приложения, лол
> Советую почитать сколько нод, например, у WhatsApp, лол.
Они на GO переезжают уже давно. Вангую там от эликсира чуть больше чем нихуя.
> Видать взломали Erlang, чтобы выйти за предел. Если тебе интересно посмотреть как это работает, и как работают необычные топологии в Erlang, я советую почитать про hidden ноды, отключение connect all и вещи типа empdless
Это не снизит нагрузку при передачи глобалстейта.
Ерланг разрабатывался для коммуникаторов всяких, для связи, а не для приложений. И сейчас не существует человека/группы которые бы пофиксили BEAM и OTP чтобы ерланг открыл для себя новую нишу.
>Вот с этим, кстати, согласен. Elixir и Erlang снимают очень много головной боли по сравнению с другими языками.
Это не плюс, потому что подобный подход порождает архитектуру которая в десятки раз медленнее других языков. Ерланг медленнее NodeJS в 10-50 раз, блядь.
Ты понимаешь че вообще происходит? Компании начинают проект с ерланга, смотрят тесты и нахуй выкидывают ерланг. Жизненный цикл приложения, лол
>>480003
Во-первых, WhatsApp на Erlang. Во-вторых, пруфы того что переезжают? Я погуглил и последнее что я нашёл это где они рассказывают как скейлят Erlang.
Что за глобалстейт? Что это значит? Какая передача глобалстейта? В кластере Erlang вообще по дефолту нет никакого глобального стейта, который нужно синкать. Есть модуль global для такого, но им очень редко вообще пользуются, потому что это редко применимо когда. Чаще всего пишут алгоритмы под свой юзкейс
Пофиксили как? Для чего?
Это ты как замерял? На какой задаче? Я вот недавно переписал часть бэкенда с Java на Elixir, сервис который парсит гигабайтные xml, и получил буст в скорости только из-за того что у меня параллельная обработка данных стала. В целом стало быстрее примерно на 40%, памяти жрёт примерно столько же.
> Они на GO переезжают уже давно. Вангую там от эликсира чуть больше чем нихуя.
Во-первых, WhatsApp на Erlang. Во-вторых, пруфы того что переезжают? Я погуглил и последнее что я нашёл это где они рассказывают как скейлят Erlang.
> Это не снизит нагрузку при передачи глобалстейта.
Что за глобалстейт? Что это значит? Какая передача глобалстейта? В кластере Erlang вообще по дефолту нет никакого глобального стейта, который нужно синкать. Есть модуль global для такого, но им очень редко вообще пользуются, потому что это редко применимо когда. Чаще всего пишут алгоритмы под свой юзкейс
> пофиксили BEAM и OTP чтобы ерланг открыл для себя новую нишу.
Пофиксили как? Для чего?
> Ерланг медленнее NodeJS в 10-50 раз, блядь.
Это ты как замерял? На какой задаче? Я вот недавно переписал часть бэкенда с Java на Elixir, сервис который парсит гигабайтные xml, и получил буст в скорости только из-за того что у меня параллельная обработка данных стала. В целом стало быстрее примерно на 40%, памяти жрёт примерно столько же.
>>479967
Ты же в курсе что RabbitMQ и Kafka это разные программы для разных задач и с разными характеристиками по латенси, throughput, доступности и всему такому?
Ты же в курсе что RabbitMQ и Kafka это разные программы для разных задач и с разными характеристиками по латенси, throughput, доступности и всему такому?
>>480236
Я не он, но я не в курсе.
Я не он, но я не в курсе.
>>480209
Что ты так перемогаешь за полторы конторки, которые сидят на эрланг с элексиром. Ты сам чьих будешь, додь?)))
Что ты так перемогаешь за полторы конторки, которые сидят на эрланг с элексиром. Ты сам чьих будешь, додь?)))
>>480209
Мда, с кем я говорю только.... Иди нахуй, школьник.
> Что за глобалстейт? Что это значит? Какая передача глобалстейта?
> Есть модуль global для такого, но им очень редко вообще пользуются, потому что это редко применимо когда.
Мда, с кем я говорю только.... Иди нахуй, школьник.
>>478162
Где они это писали/заявляли? Или опять фантазии типа вымышленного друга из дисорга?
>>479120
Выше какого рыгка? Откуда вы эту мантру взяли?
>В целом основная претензия и у тех, и у этих была не к языку, а к тому что программистов сложно искать.
Где они это писали/заявляли? Или опять фантазии типа вымышленного друга из дисорга?
>>479120
>О чём собственно и тред. Платят выше рынка не просто так, поэтому если думаете поменять стек, то Elixir это отличный вариант
Выше какого рыгка? Откуда вы эту мантру взяли?
>>478169
Наркоман что ли? У тебя 100500 разных поинтов. То
и в блоге непосредственно про Эликсир хуй да нихуя.
То
Одна вакансия где ЖЕЛАТЕЛЬНО знать эликсир.
Вся основная логика на эликсире, потэтому мы нанимаем людей которым даже в желательно не пишем знание эликсира. Звучит логично.
>Так это подтверждает мой поинт же.
Наркоман что ли? У тебя 100500 разных поинтов. То
>Так я и не прошу мне на слово верить, почитайте блоги дискорда,
и в блоге непосредственно про Эликсир хуй да нихуя.
То
>почитайте вакансии на какой стек там нанимают и в каком количестве.
Одна вакансия где ЖЕЛАТЕЛЬНО знать эликсир.
>Я не говорил что там пишут всё на Elixir, я говорил что там Elixir это основной язык бэкенда, на котором пишут основную логику.
Вся основная логика на эликсире, потэтому мы нанимаем людей которым даже в желательно не пишем знание эликсира. Звучит логично.
>>481595
https://lvivity.com/top-highly-paid-programming-languages
https://survey.stackoverflow.co/2024/technology#4-top-paying-technologies
Пожалуйста, родной.
https://www.erlang-solutions.com/blog/which-companies-are-using-erlang-and-why-mytopdogstatus/
... when Cisco revealed that it ships 2 million devices per year running Erlang at the Code BEAM Stockholm conference in 2018. This translates to 90% of all internet traffic going through routers and switches controlled by Erlang. And have you heard about Ericsson? It has Erlang at the core of its GPRS, 3G, 4G and 5G infrastructure. With a market share of 40%, there’s a high probability a program written in Erlang assigned the IP address your smartphone is using today (amongst other things).
Касательно Klarna, я почитал интернет, dev блог, посмотрел вакансии. Оказывается они остались на Erlang, хотя в какой-то момент пробовали переписать на Java.
Касательно Brex, вот тут обсуждали: https://podcast.thinkingelixir.com/61 . Я ещё какой-то подкаст с бывшим разрабом из Brex слушал, но не могу найти сейчас.
>>481610
Ну всё, победил, в Discord не пишут на Elixir. Все разрабы из интервью, их собственный блог, выступления их разрабов, сайт эликсира, их опенсорс, это всё пиздёж и провокация. Discord написан на твоём любимом языке, то есть на PHP и Javascript, можешь расслабиться, родной.
Предвосхищая ваши ответы, могу сразу сказать, на Elixir не пишут программы. Такого языка вообще не существует. Статистика про зарплаты это тоже накрученный пиздёж. Elixir в 100 раз медленнее чем Python, уродливее чем JavaScript, ваканский на нём нет, а за работу на нём нужно ещё приплачивать. Но это не имеет значения, ведь на нём всё равно ничего не пишут, да и самого языка фактически не существует
> Выше какого рыгка? Откуда вы эту мантру взяли?
https://lvivity.com/top-highly-paid-programming-languages
https://survey.stackoverflow.co/2024/technology#4-top-paying-technologies
Пожалуйста, родной.
> Что ты так перемогаешь за полторы конторки
https://www.erlang-solutions.com/blog/which-companies-are-using-erlang-and-why-mytopdogstatus/
... when Cisco revealed that it ships 2 million devices per year running Erlang at the Code BEAM Stockholm conference in 2018. This translates to 90% of all internet traffic going through routers and switches controlled by Erlang. And have you heard about Ericsson? It has Erlang at the core of its GPRS, 3G, 4G and 5G infrastructure. With a market share of 40%, there’s a high probability a program written in Erlang assigned the IP address your smartphone is using today (amongst other things).
> Где они это писали/заявляли?
Касательно Klarna, я почитал интернет, dev блог, посмотрел вакансии. Оказывается они остались на Erlang, хотя в какой-то момент пробовали переписать на Java.
Касательно Brex, вот тут обсуждали: https://podcast.thinkingelixir.com/61 . Я ещё какой-то подкаст с бывшим разрабом из Brex слушал, но не могу найти сейчас.
>>481610
> Вся основная логика на эликсире, потэтому мы нанимаем людей которым даже в желательно не пишем знание эликсира
Ну всё, победил, в Discord не пишут на Elixir. Все разрабы из интервью, их собственный блог, выступления их разрабов, сайт эликсира, их опенсорс, это всё пиздёж и провокация. Discord написан на твоём любимом языке, то есть на PHP и Javascript, можешь расслабиться, родной.
Предвосхищая ваши ответы, могу сразу сказать, на Elixir не пишут программы. Такого языка вообще не существует. Статистика про зарплаты это тоже накрученный пиздёж. Elixir в 100 раз медленнее чем Python, уродливее чем JavaScript, ваканский на нём нет, а за работу на нём нужно ещё приплачивать. Но это не имеет значения, ведь на нём всё равно ничего не пишут, да и самого языка фактически не существует
>>481595
https://lvivity.com/top-highly-paid-programming-languages
https://survey.stackoverflow.co/2024/technology#4-top-paying-technologies
Пожалуйста, родной.
https://www.erlang-solutions.com/blog/which-companies-are-using-erlang-and-why-mytopdogstatus/
... when Cisco revealed that it ships 2 million devices per year running Erlang at the Code BEAM Stockholm conference in 2018. This translates to 90% of all internet traffic going through routers and switches controlled by Erlang. And have you heard about Ericsson? It has Erlang at the core of its GPRS, 3G, 4G and 5G infrastructure. With a market share of 40%, there’s a high probability a program written in Erlang assigned the IP address your smartphone is using today (amongst other things).
Касательно Klarna, я почитал интернет, dev блог, посмотрел вакансии. Оказывается они остались на Erlang, хотя в какой-то момент пробовали переписать на Java.
Касательно Brex, вот тут обсуждали: https://podcast.thinkingelixir.com/61 . Я ещё какой-то подкаст с бывшим разрабом из Brex слушал, но не могу найти сейчас.
>>481610
Ну всё, победил, в Discord не пишут на Elixir. Все разрабы из интервью, их собственный блог, выступления их разрабов, сайт эликсира, их опенсорс, это всё пиздёж и провокация. Discord написан на твоём любимом языке, то есть на PHP и Javascript, можешь расслабиться, родной.
Предвосхищая ваши ответы, могу сразу сказать, на Elixir не пишут программы. Такого языка вообще не существует. Статистика про зарплаты это тоже накрученный пиздёж. Elixir в 100 раз медленнее чем Python, уродливее чем JavaScript, ваканский на нём нет, а за работу на нём нужно ещё приплачивать. Но это не имеет значения, ведь на нём всё равно ничего не пишут, да и самого языка фактически не существует
> Выше какого рыгка? Откуда вы эту мантру взяли?
https://lvivity.com/top-highly-paid-programming-languages
https://survey.stackoverflow.co/2024/technology#4-top-paying-technologies
Пожалуйста, родной.
> Что ты так перемогаешь за полторы конторки
https://www.erlang-solutions.com/blog/which-companies-are-using-erlang-and-why-mytopdogstatus/
... when Cisco revealed that it ships 2 million devices per year running Erlang at the Code BEAM Stockholm conference in 2018. This translates to 90% of all internet traffic going through routers and switches controlled by Erlang. And have you heard about Ericsson? It has Erlang at the core of its GPRS, 3G, 4G and 5G infrastructure. With a market share of 40%, there’s a high probability a program written in Erlang assigned the IP address your smartphone is using today (amongst other things).
> Где они это писали/заявляли?
Касательно Klarna, я почитал интернет, dev блог, посмотрел вакансии. Оказывается они остались на Erlang, хотя в какой-то момент пробовали переписать на Java.
Касательно Brex, вот тут обсуждали: https://podcast.thinkingelixir.com/61 . Я ещё какой-то подкаст с бывшим разрабом из Brex слушал, но не могу найти сейчас.
>>481610
> Вся основная логика на эликсире, потэтому мы нанимаем людей которым даже в желательно не пишем знание эликсира
Ну всё, победил, в Discord не пишут на Elixir. Все разрабы из интервью, их собственный блог, выступления их разрабов, сайт эликсира, их опенсорс, это всё пиздёж и провокация. Discord написан на твоём любимом языке, то есть на PHP и Javascript, можешь расслабиться, родной.
Предвосхищая ваши ответы, могу сразу сказать, на Elixir не пишут программы. Такого языка вообще не существует. Статистика про зарплаты это тоже накрученный пиздёж. Elixir в 100 раз медленнее чем Python, уродливее чем JavaScript, ваканский на нём нет, а за работу на нём нужно ещё приплачивать. Но это не имеет значения, ведь на нём всё равно ничего не пишут, да и самого языка фактически не существует