Сегодня хочу рассказать тебе о прекрасном функциональном языке для написания неубиваемых распределённых систем, а более конкретно вебни на бэке, больших soft-realtime систем и IoT говен. Называется он Elixir, а работает он на виртуальной машине real human BEAM, на которой ещё работает язык Erlang
Немного истории
Эликсир это современный язык, построенный поверх языка Erlang с блекджеком и лисповыми макросами. У этих языков полный интероп в обе стороны, но при этом эликсир лишает вас этого удовольствия написания Сам язык Erlang появился в компании Ericsson как язык для написания максимально отказоустойчивых телекоммуникационных систем. Именно из желания создать среду для написания максимально отказоустойчивых систем появились все основные фичи.
Основные фичи
⚹ Ахуенно приспособлен к разработке параллельных и конкуррентных программ. Эликсир способен запускать мильоны процессов-акторов, работающих асинхронно, с различными приоритетами и всем таким. Эти процессы не делят память и общаются через пересылку сообщений.
⚹ Ахуенно приспособлен к разработке распределённых систем. Все основные проблемы написания распределённых систем вроде сихнронизации монотонных часов, общения между машинами, поиска машин, heartbeat-ы, группы процессов, gossip-ы уже включены в язык
Любая достаточно сложная распределённая программа содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Erlang.
⚹ Ахуенно приспособлен к разработке отказоустойчивых систем. Что делают кубы, когда падает сервис? Они перезапускают его. Эрланг делает то же самое, только не с сервисами, а с процессами, что значит что неожиданное исключение в одной части функционала никак вообще никак не заденет другой функционал.
⚹ Ахуенный тулинг. В отличие от эрланга с его хэдерами, 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. Забугорных вакансий значительно больше и они охотно нанимают разработчиков с опытом. Самое важное качество при найме это не знание самого языка, а софт-скиллы и общее понимание веб-разработки как таковой, так что придётся социализироваться
Вопросы?
ну и нахуй нужен такой язык?
Привет, Сычёв. Вылезай из берлоги, родной, самое время заводить себе друзей-анимешников в мире программирования
>Чтобы стать джуном на эликсире опытному бэкендеру нужно не больше месяца
И зачем опытному бекендеру становится джуном с непонятными перспективами и дропом зп?
> друзей
> анимешников
> в мире программирования
тройное ненужно
Дак дропа не будет. Я имел в виду, что знание языка будет уровня джуна. Я надеюсь тебе, дорогой умница-анон, не нужно пояснять, что позиция состоит не только из знания основного языка разработки
В этом и есть вся перелесть эликсира: если ты разбираешься в вебе, в распределённых системах, то эликсиру тебя научат на месте работы, при этом, зп только вырастет
Эх, а я так хотел с тобой подружиться. Няшились бы с тобой под пледиком, посматривая GTO и перекидывая друг другу лямбдочки по distributed erlang
> эликсиру тебя научат на месте работы
Если тебя нанимают как опытного бекендера, от тебя ждут, что ты сам будешь обучаться всё таки.
Почему? Вообще понятие сам/несам какое-то не совсем ясное, ведь ты в любом случае будешь задавать вопросы и на них в любом случае будут отвечать.
Базовый уровень эликсира подтягивается за день/неделю в зависимости от одарённости на https://elixirschool.com , а всё остальное узнаётся на месте. И если тебя нанимают (а тебя нанимают), то люди точно готовы отвечать на твои вопросы касательно собственного стека
Elixir хуйня; работы нет
Приходи через 4 лет
/трет
Вопросы касательно собственного стека != банальные вопросы по языку, которые ты можешь сам найти в доках.
> понятие сам/несам какое-то не совсем ясное
Имеется ввиду, что ты сначала сам попытаешься решить свою проблему, а только потом пойдёшь спрашивать у других. И, если ты действительно разработчик с опытом, то вопросы будут касаться либо каких-то крайних тонкостей стека, либо доменной области, что явно не соответствует тезису "тебя научат на месте работы".
>Базовый уровень эликсира подтягивается за день/неделю
Ну ок, вижу на hh две вакансии на джуна элексира без опыта работы на нем, зп до 130к, явно для опытного будет дроп.
https://hh.ru/vacancy/45430273
Один стартап с требованием верстать шаблоны для фронта и смутным
>Это стартап поэтому работать нужно много.
Второе это
https://hh.ru/vacancy/45531785
И все, нет больше вакансий в россиюшке.
Джунов никто и не ищет на эликсир. Это язык не для начинающих программистов
Большинство вакансий на эликсире не требуют коммерческого опыта разработки. Достаточно запилить какой-нибудь TODO-list на местных рельсах, чтобы показать что ты знаешь язык и вкатиться в нормальную работу
> вакансий в россиюшке
Во-первых, российский ойти рынок вообще не показатель. Во-вторых, ты реально в этой стране хочешь остаться? В-третьих, вот тебе ахуенный план: ты тут потеешь два года в какой-нибудь конторке набивая экспу и опыт, а потом уезжаешь забугры востребованным специалистом. Лично я и пара моих знакомых такое провернули
> нет больше вакансий
Вакансий и правда мало, но и количество кандидатов пропорционально меньше. И если учесть что джуны в эликсире никому не нужны, это ещё неплохое колчество вакансий
> явно для опытного будет дроп
Опять же, опытный чувак свапает стек и устраивается точно не на джуновскую вакансию. Это будет как минимум миддл, а опыт на руби конвертируется почти 1 к 1.
Поэтому я и завёл этот тред, в эликсире реально не хватает опытных разработчиков. И опытных не в плане знания самого эликсира, а в плане понимания вебдевелопмента
Серьезно. Эликсир классный язык, но работы нет, изучать его имеет смысл только если в рамках имеющейся компании и продукта что-то на него переписывать и то не факт, ведь нет работы -> нет спецов.
Под словами "тебя научат на месте работы", я имел в виду что тонкостям эликсира тебя реально обучат на месте работы.
Хороших разработчиков на эликсире очень мало, поэтому компании и идут на такой шаг: берут людей без опыта в эликсире, но с мозгами, и делают из них эликсирщиков
Опять же, базовые вещи касательно эликсира учатся за день-неделю, я это написал. Тонкости касательно эликсира уточняются на работе. Вообще не может быть такого чтобы эти тонкости не уточнялись на работе, тебя же блять наняли и знали что ты не шибко эликсирщик, а значит были к такому готовы
>Лично я и пара моих знакомых такое провернули
Спокойно реализуется и на других языках
>Опять же, опытный чувак свапает стек и устраивается точно не на джуновскую вакансию. Это будет как минимум миддл
Без опыта работы с языком и экосистемой сильно сомневаюсь, что возьмут на мидла, даже на линкедине нет такого, по крайней мере я не нашел
>а опыт на руби конвертируется почти 1 к 1
Скажи что еще и без знания OTP и распределенных систем можно вкатится. От руби там только куски синтаксиса.
> опыт на руби конвертируется почти 1 к 1
Забываешь почти все свои ООП шаблоны, правила организации структуры проекта, подходы к сторонним сервисам (типа сайдкика), а потом сдвигаешь парадигму с императивщины на функциональщину (а научиться думать по-другому - это не так просто).
Если ты действительно опытный разработчик, это для тебя не будет чем-то непосильным, но о конвертации 1 к 1 тут точно говорить нельзя.
Справедливости ради, помимо кусков синтаксиса там есть ещё феникс, который очень пытается мимикрировать под рельсы.
> изучать его имеет смысл только если в рамках имеющейся компании и продукта что-то на него переписывать
Я понимаю почему ты так думаешь, анон, но он не совсем верно. Вакансии существуют, проекты на эликсире существуют, при чём в том количестве, которое вполне реально потянуть. Тут не нужно рвать жопу, нужно просто поднять себе базовый лвл эликсира.
Я не заставляю менять стек и не говорю что у тебя, анон, всё обязательно получится, я лишь говорю что язык ахуенный, и работа на нём есть, реально есть. И если ты, как человек любящий погроммирование, уделишь ему свободное время, то, помимо банальной смены рутины и удовольствия от погроммирования на классном языке, ты можешь ещё и получить классную работу за бугром
> liveview
Такая тема есть, но никто не заставляет тебя это использовать. Вообще, у рубистов это кривовато работает немного. На эликсире это нативнее, быстрее, и уже есть кучи гайдлайнов касательно PETAL стека
>там есть ещё феникс, который очень пытается мимикрировать под рельсы
Это кстати нездоровая хуйня, что руби был языком одного фреймворка, что у эликсира из популярных только феникс
>ты можешь ещё и получить классную работу за бугром
Что мешает получить работу за бугром на любом другом ЯП?
На сколько я знаю, у рубей сейчас не один фреймворк. Та же синатра. У эликсира из альтернатив только `Plug.Router`, который абсолютно бесполезен для сколько-нибудь расширяющегося веб-приложения. Есть ещё несколько мёртворождённых обвязок вокруг последнего, но они не в счёт, т.к. не развиваются.
Но для полноценного развития альтернативных фреймворков нужны компании, которые будут вливать в это деньги, а для этого нужна аудитория пошире, чем у эликсира. Так что всё идёт вполне естественным ходом.
> Скажи что еще и без знания OTP и распределенных систем можно вкатится
OTP не нужно знать, а распределённые системы желательно хотя бы на троечку. Типа знать что такое логические часы и клиент-сервер будет достаточно для успешного свапа на миддла
> Спокойно реализуется и на других языках
Это правда, я не спорю. Я это говорил лишь к тому что российский рынок ойти вообще не показатель
> Без опыта работы с языком и экосистемой сильно сомневаюсь, что возьмут на мидла, даже на линкедине нет такого, по крайней мере я не нашел
Я понимаю твою обеспокоенность, дорогой анон. Вот то что я нашёл:
https://t.me/proelixir/184763
Вот сюда через несколько месяцев будут искать свежую кровь: https://t.me/proelixir/183217
https://t.me/proelixir/172553
> `Plug.Router`
Что? Это просто модуль, который роутит по хэндлерам, это не вебфреймворк
> Есть ещё несколько мёртворождённых обвязок вокруг последнего, но они не в счёт, т.к. не развиваются.
Навскидку есть такие фреймворки, каждый из которых работает: cowboy, plug, phoenix, mochiweb, ash
Да, phoenix сейчас сильно популярен, но пока что он покрывает 99% кейсов
> нужны компании, которые будут вливать в это деньги
За эликсиром стоят большие компании, списочек вот тут: https://elixir-lang.org/cases.html
> OTP не нужно знать
Только отчасти правда. У тебя достаточно готовых либ, чтобы делать какие-то банальные вещи из крудоебли, действительно. И OTP для них понимать не надо. Но, если у тебя возникнет какая-то сложная проблема с одной из таких либ, где тебе придётся лезть в потраха, либо если тебе придётся написать что-то своё (вполне реальный кейс, учитывая, что язык всё ещё активно развивается), то без OTP будет сложно.
Понятное дело, что OTP рано или поздно придётся выучить. Я говорил о том, что его не особо нужно знать для устройства на работу.
Это не сильно сложная вещь, которая познаётся прочтением книжки Elixir in Action 2 за пару дней
>https://t.me/proelixir/184763
>5+ years of professional development using Elixir/Ruby
Мимокроку не залететь, только рубисту, и то не факт, что элексиром не завалят на собесе
>https://t.me/proelixir/183217
>опыт работы с Elixir от 1-го года
>https://t.me/proelixir/172553
Юг. Киев, ремоут для жителей Беларуси.
Русичи в пролете
> Это просто модуль, который роутит по хэндлерам
Если в твоём микросервисе пара эндпоинтов с общением исключительно по хттп, и ты не планируешь как-то это расширять, то тебе его хватит вместо полноценного веб-фреймворка. plug предоставляет достаточную гибкость, чтобы писать веб-приложения, не подключая ничего больше. Только без вьюшек придётся обойтись. :)
> есть такие фреймворки: cowboy, plug
Это не фреймворки. cowboy -- сервер. plug -- обвязка вокруг него, чтобы удобно было писать вебню. Хотя, в стандартную поставку входят полезные самодостаточные вещи (как я описал выше).
> mochiweb
Какая-то либа для эрланга. 404 на ссылку на доки на хексдоксе и никакого описания в ридми. В любом случае эрланг несколько ниже эликсира в плане метапрограммирования, так что я бы не стал это использовать без самописных (или кем-то написанных) обвязок.
> ash
Сомнительная затея.
> опыт работы с Elixir от 1-го года
Не значит ровно нихуя. Всем насрать на твой реальный опыт. Если ты адекватный и дома выучил основные поинты, всё окей
> Мимокроку не залететь, только рубисту
Это правда, но шибко мудрым эликсирщиком не нужно быть, а я именно об этом и говорил
> Русичи в пролете
ХРЮК
>Серьезно. Эликсир классный язык, но работы нет
Я уже 5 лет пиздярю на elixir за деньги, вакансий не так много, но работы хватает, если опыт какой-никакой есть - hr'ы даже со своими 5 вакансиями заебывают предложениями
>>2082999
>хуйню со своим liveview
Так крутая хуйня же!
> cowboy -- сервер
А как же cowboy_rest? Да и встроенного функционала хватает. Там есть аналоги для самых нужных плагов из Plug
> plug -- обвязка вокруг него
И чем это не фреймворк, дорогой?
> ash Сомнительная затея.
А мне кажется что это ахуенная идея. И кто прав?
> mochiweb
Спасибо анон, я перепутал. Я хотел сказал n2o и nitro
>Так крутая хуйня же!
Шаблонизаторы это нихуя не крутая хуйня, шаг вне стандартного функционала и приходится страдать.
> шаг вне стандартного функционала и приходится страдать
Что конкретно ты имеешь в виду?
Но вообще я соглашусь, что liveview не серебряная пуля. Написать интерактивную админку или прочую одностраничную интерактивную хуйню будет очень легко, просто и быстро. Это именно то, что нужно в мире IoT и на первых этапах стартарпататов
> cowboy_rest
Как я уже сказал, использовать эрланговские либы, которые выиграли бы от метапрограммирования, в эликсире напрямую, не самая лучшая идея.
> > plug -- обвязка вокруг него
> И чем это не фреймворк, дорогой?
Он, конечно, фреймворк, но слишком бедный для сколько-нибудь сложного приложения (как я упомянул здесь >>2083033)
> > ash Сомнительная затея.
> А мне кажется что это ахуенная идея. И кто прав?
Идея избавиться от бойлерплейта - это, конечно, хорошо. Только оно слишком похоже на рельсы, чтобы на этом было не больно писать. :)
На самом деле, в реальных приложениях у тебя не так много круда - как минимум есть всевозможные сайд-эффекты на разных действиях. Тебе может понадобиться создать какую-нибудь промежуточную сущность, послать ивент в шину событий, добавить сохранение в какой-нибудь ets для кэша на апдейте, и т.д. Подход из голого феникса с экто позволяет тебе вставить эту логику там, где тебе удобно, оставляя просто для дополнительных оптимизаций. Здесь же придётся извращаться, подстраиваясь под фреймворк, чтобы заставить это просто работать.
Когда у тебя разрастается логика, реального бойлерплейта становится не так уж и много.
И всё бы хорошо, если бы оно навешивалось поверх существующих механизмов феникса и экто, но она делает свои не переиспользуемые обёртки. Так что даже возможности переписывать отдельные куски, когда логика станет сложнее, у тебя нет.
Ещё отдельный минус для ash - расположение файлов в туториале (ресурсы в lib/my_app/resources/*). Феникс притащил этот рак из рубей, раскидав контроллеры и вьюхи по отдельным директориям, введя соглашение об именовании модулей противоположным способом. Теперь ещё и этот рак в бизнес-логике. В эликсире (как и во многих других фп-языках с нормальными модулями) есть своё соглашение по именованию модулей и файлов, которое позволяет довольно гибко и логично организовать структуру проекта, а здесь они просто забили на это болт, введя дополнительные проблемы для людей, которые потом будут на этом писать.
> слишком бедный для сколько-нибудь сложного приложения
Почему ты так думаешь? Во-первых, плаг совместим со всем, что есть в фениксе. Во-вторых, плаги пишутся очень просто. В-третьих, у меня писались сложные приложения на плаге
Насчёт ash я согласен, он не особо гибкий. Но он и не стремится таким быть, а просто существует как фреймворк для ультрабыстрого крудошлёпства, типа такой postgrest, только чуть-чуть умнее
А ещё они прибежали в эликсир и утащили себе паттерн-матчинг.
На туториал вообще нужно сквозь пальцы смотреть. Большая часть туториала нужна чисто чтобы рубист писал на эликсире как на руби, только дописывая do в начале блока
Вообще такое положение файлов не навязывается, но мне оно нравится, потому что оно защащет от смешивания бизнес-логики-модели от контроллеров и вьюх
> > слишком бедный для сколько-нибудь сложного приложения
> Почему ты так думаешь?
Плаг не просто совместим со всем, что есть в фениксе. Феникс работает через плаг.
Но я говорил не об применимости плага в веб-приложении (без своих плагов было бы сложно), а об использовании исключительно плага без феникса. Написать самописную вьюшку для пары эндпоинтов - легко, но когда у тебя появляется пачка эндпоинтов, тебе уже нужен какой-то общий механизм рендеринга, чтобы не писать бойлерплейт.
Плюс, если у тебя не какой-нибудь специфичный микросервис, который ты не планируешь расширять дальше, тебе с большой вероятностью понадобятся какие-нибудь веб-сокеты. Или что-нибудь ещё из стандартной поставки феникса. В конечном итоге ты придёшь к тому, что тебе надо всё переделать под феникс (либо попытаться воткнуть его куда-то между, но это, полагаю, будет ещё больнее).
Помимо этого в фениксе у тебя есть куча удобных механизмов вроде пайплайнов и скоупов. У тебя есть довольно гибкая система рендеринга во вьюшках (которую ты можешь расширить на любой формат помимо дефолтных html и json в несколько строк). Есть система content negotiation, которая позволяет не дублировать код, если тебе надо отдавать что-то сразу в нескольких форматах.
Опять же, соглашусь, феникс включает в себя плаг. Но если ты уверен, что тебе достаточно будет только плага, нужно выбирать именно его. Как ты сказал, микросервисы, ресты, самописные HTTP API это его область применения.
Но ресты и микросервисы это не обязательно простые приложения, у них просто требований касательно вебни меньше. Всякие сложные и развесистые ресты на плаге писать одно удовольствие
Между тем, напомню, что у кложуристов вообще ничего кроме местного плага (который ring) нет
Ты прав, но не всем приложениям нужен SSR, вебсокеты, или несколько скоупов
>Именно из желания создать среду для написания максимально отказоустойчивых систем появились все основные фичи.
В чем его отказоустойчивость проявляется, что нельзя использовать другой язык?
В двух словах, отказы бывают таких видов:
1) Софт падает
Это может быть баг в программе. Неотловленные баги чинятся одним способом: рестартом. Эрланг изолирует программу в множество относительно независимых процессов, если процесс падает, он перезапускается по определённой стратегии. Получается, что некоторые незначительные аномалии не будут полностью ронять систему, а будут просто чуть-чуть замедлять её общее
состояние
Для отлавливания багов в компайле у эрланга и эликсира есть тайпчекер и крутые линтеры
2) Хардварь падает
Для этого программы должны работать в кластере. Эрланг содержит самый лучший тулинг для разработки распределённых систем
2.1) Падает сеть
Для этого программы должны уметь трекать причины отказа, и в зависимости от этого определять своё поведение при сплитах и прочем
Справедливости ради, в реальной разработке часто приходится пилить всякие микросервисы без феникса, на голом elixir. С рубями такое редко бывает, разве что гемы на голых пишут.
>Шаблонизаторы это нихуя не крутая хуйня
Ну я бы не сказал, что это прям шаблонизатор, это крутая хуевина для рендеринга html на стороне сервера, если немного разобраться в этом, то понимаешь, что затея пиздатая. В реально разработке пока что не приходилось это юзать, а для себя дома ковырял - ощущения необычные, понравилось (тем более я ненавижу js ебоманый)
>В реально разработке пока что не приходилось это юзать, а для себя дома ковырял - ощущения необычные, понравилось
Это не показатель, захотят у тебя дизигнеры на работе сделать окошко более закругленным и все.
Пусть делают, не вижу проблем. Можно же часть страницы на обычном html написать и только в нужные части liveview встроить.
>Можно же часть страницы на обычном html написать и только в нужные части liveview встроить
И тут появляется анимация, которая изменяет сразу два компонента.
Хз в какую сторону ты мыслишь, никто не советует и не пишет все подряд с liveview - это хуевина для специфичных проектов, где с ней реально можно удобно делать интерактивности всякие без привлечения фронтендеров даже
Типа, можно вот такие хуйни писать на изи без js
Ты вообще работал в компаниях, где есть свой отдел с дизайнерами?
Я юзал liveview на большом пендосском проекте. Всё нормально и с анимациями и с интерактивностью. Типа liveview спокойно живёт вместе с js
Всякие банальные интерактивные вещи на нём делать одно удовольствие. Если нужны какие-то особенные анимации, всё это на бэке пишется вообще без проблем
Единственное, это бывают моменты когда что-то прям ну очень нужно на клиенте обсчитать, но это совершенно не сложно и вполне себе уживается вместе с liveview
Да, но я бэкенд пишу и никак с дизайнерами не взаимодействую вообще, с liveview я только дома игрался
Посмотрел, в вакухах очередные "Сильным плюсом будет опыт в RoR". Элексиристы вообще из других языков бывают?
Много кто из эрланга. Есть много ценителей ФП. Лично я из питона пришёл
И какой опыт в эрланге и какая зп? Мне на го/пистон недавно предлагали перекатится с 220к, почти без дропа.
Ну, чисто исторически так сложилось, что большинство с рубей перекатились, собственно и сам разработчик elixir'a раньше в рельсах был в кор тим. А так да, есть еще бывшие эрлангисты >>2083321
На нем можно писать приложухи для десктопа и компилировать их в ехе?
Хз, я последние 3 года феникс встречаю только как подкладку под Absinthe. В теории его можно вообще выпилить нахуй, и прикрутить абсент к ковбою через плаг, но лень, там все равно оверхед минимальный.
Феникс, я так понимаю, нужен в основном всяким хуяк-хуяк-фулстекам для проектов с SSR, которых, по-идее, много во фрилансе, или соло-стартапщикам, которым нужно быстро накидать МВП. С другой стороны, феникс, как и рельсы, настолько хорош, что иметь больше одного фреймворка под эти задачи просто нет смысла.
Чисто теоретически -- да, но никто этим не занимается
Для десктопа есть две-три либы: wxWidgets, elixir-desktop поверх неё и ещё одна, название которой я забыл
Для компиляции в бинарник есть bakeware
Чел мне похуй, я программирую, потому что это блять интересное времяпровождение, в отличии от того, чтобы лежа на диване часами смотреть в потолок. Особенно интересно отрисовывать все в окне, а не буковки в консоли или на ебучем сайте (хотя видимо к этому я тоже скоро приду)
Я php разраб с 4 годами опыта, и у меня 60% предложении на линкед ин - эликсир разработчик. Хрюши прям настойчиво предлагают собесы, хотя я им говорю, что не работал с эликсиром совсем, и вообще во фронт перекатываюсь.
Вакансии полно, просто они не для всех.
>Хрюши прям настойчиво предлагают собесы
Они всем предлагают, чел. Им KPI нужно выполнять.
>Им KPI нужно выполнять.
И? Вакансии то есть. А пройдет анон-перекат собес или нет - это другой вопрос.
В любом случае, нормальному бэкэндеру не составит труда перекатиться, т.к. стек технологии в большинстве вакансии совпадает на 60-80%
Звучит как антиреклама языка. Если хочешь начать на нем проект, то тебе нужно нанимать людей без опыта в нем и платить им больше по рынку, что бы у них дропа ЗП не было сильного, да и не факт, что ты найдешь таких за приемлемое время. Большинству тимлидов будет легче взять другой язык и напедалить микросервисную архитектуру, чем все это.
> людей без опыта в нем и платить им больше по рынку
Язык учится за две недели, он жутко простой. Платить больше чем рынок не нужно, достаточно платить также как раньше или чуть-чуть больше. На эликсир переходят как минимум потому что язык очень няшный
> не факт, что ты найдешь таких за приемлемое время
> легче взять другой язык и напедалить микросервисную архитектуру
Даже для большого проекта нужно не больше 5-6 элксирщиков. В начале проекта нужно не больше двух. Язык очень высокоуровневый и очень хорошо приспособлен к вебне. На найм гоферов или кого-то ещё уйдёт ещё больше денег и времени, потому что банально потребуется больше человек для эквивалентной разработки
>Язык учится за две недели, он жутко простой.
Чет вспомнил, как плюсовиков в проекте заставили на пистоне писать, они там свой csv ридер сделали, так как с библиотекой не были знакомы. Утверждение, что можно быстро пересесть на другой язык и писать хороший код очень сомнительна.
Понятное дело, что пересаживаться нужно под чьим-то присмотром. Рубисты реально за две недели пересаживаются, все остальные максимум за месяц
>Если хочешь начать на нем проект, то тебе нужно нанимать людей без опыта в нем и платить им больше по рынку, что бы у них дропа ЗП не было сильного, да и не факт, что ты найдешь таких за приемлемое время. Большинству тимлидов будет легче взять другой язык и напедалить микросервисную архитектуру, чем все это.
Есть такие ребята Klarna самый дорогой финтех стартап европы, в свое время много писали на Эранге/Эликсире https://github.com/klarna?q=&type=&language=erlang На конференциях выступали.
А теперь у них джава, питон и пых https://jobs.lever.co/klarna/?team=Engineering
Я их спрашивал почему отказались, были какие-то технические претензии у Эрлангу какие именно чувак был не в курсе и проблемы с поиском разработчиков.
Откуда тут взяться вопросам, если все думают, что нет работы и не вкатываются, а у тех, кто вкатился, вопросов нет?
нахуй ты создал тред мудак, и так язык уже почти мейнстрим стал, уже пора выкатываться скоро, а ты еще ускоряешь еблан
> А теперь у них джава, питон и пых
Ну там также и эрланг. Количество вакансий не показатель. К тому же, существуют компании, которые меняют жаву на эрланг. Так что попробуй ещё раз, анон
Искать разработчиков на эрланг раньше было и правда сложно, но сейчас эликсирщиков очень много, да и пересадить рубиста на эликсир будет совсем не сложно
> Работы нет пацаны
Дорогой анон, я понимаю твои тревоги, но ты хотя бы просто так без пруфов не вкидывай, хорошо? Я прямо сейчас могу тебе переслать с почты около 8 активных вакансий в РФ и примерно в 10 раз больше забугорских. Если поискать в интернетах, то их количество окажется сильно больше
>Ну там также и эрланг. Количество вакансий не показатель.
Если их ноль - то показатель. Я смотрел их вакансии еще год назад и там тоже был ноль. Плюс ты наверное не заметил, но
>Я их спрашивал почему отказались
И ответ был, что да Эрланг команды остались и сервисы на Эрланге никто не выкидывает, но новые не пишут. У них теперь Эрланг - легаси.
Дай угодаю, в требованиях или опыт на эликсире или на рубях?
>в требованиях или опыт на эликсире
Шок-контент, в требованиях к "Ищем разработчика на Х" есть опыт работы с X. Охуеть!
Тогда ты нахуя нам вкатываться предлагаешь, если вакансии не для 99% разрабов?
>если вакансии не для 99% разрабов?
???
А какого хуя так должно быть? Воспринимай это как узкоспециализированную технологию что ли. Если какой-то опыт набьешь, то без работы потом уже точно не останешься.
ЗП От 20 000 до 50 000₽ это конечно такое себе, но я в свое время джуном вообще за 18к вкатывался. Так что кому надо - пиздуйте, набивайте коммерческий опыт и перекатывайтесь в компанию получше.
Провтыкал, что там Самара без удаленки, но похуй, может внезапно кто-то оттуда есть
>не упало
Тоже нормально спал, в докере рестарт настроил и все
И че, каждый раз целый сервис рестартится из-за одной ошибки?
Только если все совсем плохо, а так только воркер в сервисе
А в эликсире рестартится только один процесс. Типа, если падает один веб-хэндлер, то падает только он и это никак не влияет на производительность
>А в эликсире рестартится только один процесс.
У нас тоже
>Эх, я вот хорошо выспался за выходные, а вы как? В Sentry около 100 эксепшонов за выходные и при этом нихуя даже близко не упало
К сожалению ваша транзакция проебалась, но хорошие новости в том, что наш разработчик выспался.
Какой опыт? Как вкатился? Сколько получаешь?
Ну и самое главное, какие ощущения?
Увожаемо, увожаемо. Показывай классный опенсорс
Из интересного на эликсире, я нашёл realtime, который стримит изменения базы данных, которые получает через протокол репликации
Так падажжи ебана, а ООП - не декларативщина? Меня обманули?
Кстати тыщу лет ничего не слышал от него.
Насколько я помню, он плохо относился к Elixir, не делал ни одного коммита в какой бы то ни было открытый эликсир проект, да и эрливидео никакого отношения к мембране (которая намного больше и интереснее) не имеет.
ООП менее декларативный чем иммутабельное ФП.
Делкаративность и императивность это скорее спектр, чем грань
Но ведь ФП про явный вызов функций и явную передачу аргументов им, тогда как в ООП можно просто вызвать метод, который сделает что-то под капотом и вернёт что надо. Это ли не декларативнее?
Понавыдумывают терминов, ебучие погромисты
>Но ведь ФП про явный вызов функций и явную передачу аргументов им
Паттерн матчинг добавляет в это все декларативщину
Пример на руби:
def time(&block)
t1 = Time.now.to_f
yield
t2 = Time.now.to_f
t2 - t1
end
time { some_function() } # => 0.15946728
Гуглил, везде какие-то монстры на сто строк. Неужели так просто нельзя?
>Но ведь ФП про явный вызов функций и явную передачу аргументов им
>в ООП можно просто вызвать метод, который сделает что-то под капотом и вернёт что надо
1) А функция не делает что-то под капотом и не возвращает что надо?
2) Метод уже перестал быть функцией?
3) В методы ничего передавать не надо и в инициализацию класса тоже?
Я не спорю. Я вообще так считаю, что у ООП и ФП куда больше общего, чем различий, просто реализованы эти абстрактные идеи по-разному.
Есть такая штука referential transparency, это про отсутствие побочных эффектов и про возможность заменить вызов функции значением, которое она вернула бы.
Так вот из referentially transparent штуковин легче собрать декларативную штуку, а без этого свойства есть вероятность написать спагетти-код - это как бы противоположность декларативного.
> а без этого свойства есть вероятность написать спагетти-код - это как бы противоположность декларативного.
Ну это уже полная религиозная шиза, затирать, что на ФП языках спагетти код не возможен, и что он возможен только если писать декларативно. Сразу видно, что человек не разбирал ни одной рекурсии, написанной свежеиспеченным адептом ФП. В большинстве случаев, написать декларативный цикл с мутацией выйдет ГОРАЗДО проще и читаемее, чем лепить редьюсы или боже упаси рекурсии для реализации той же логики. Хоть ты обосрись с ФП, но набор команд "добавь к х единицу" воспринимается человеческим мозгом в сто раз привычнее. И как в таковой, в мутации стейта ничего плохого нет(программа без мутации стейта может существовать только на бумаге, а не выполняться в компьютере), плохой она становится только если стейт протекает и начинает изменяться из неожиданных мест в неожиданное время. Но код можно испортить тысячей разных способов, в которых никаких стейтов и близко нет.
> написать декларативный цикл с мутацией выйдет ГОРАЗДО проще и читаемее, чем
ну это уже получается императивный цикл, какой-нибудь foreach или map уже более декларативны.
самый известный пример декларативного языка - это sql.
> И как в таковой, в мутации стейта ничего плохого нет, плохой она становится только если стейт протекает и начинает изменяться из неожиданных мест в неожиданное время.
ну вот когда стейт изменяется из неожиданных мест в неожиданное время - это ведь точно не декларативно, так? что-то в этом роде я и пытался сказать.
>ну это уже получается императивный цикл
Там я хотел сказать "не-декларативный", т.е тот самый якобы "спагетти-код - противоположность декларативного". В двух местах, где было "декларативно" должно быть "не декларативно", ну 5 утра хули.
Работа время от времени появляется, особенно много вакансий зарубежом, а спецов по Elixir реально не хватает и готовы брать на сеньорские позиции с 2-3 годам опыта на каком-нибудь Руби/Питоне/Go. А уж если есть опыт с Erlang/Elixir и вообще шаришь в CS и архитектуре, то с руками отрывают.
мимо 6 лет на эликсире
Что ты притащил сюда свинья? Забери это говно и удали тред.
Буквально на днях звали оттуда на собеседование. Так что Erlang у них еще используется.
Я ебал JS и Python.
JS потому что JS.
А Python потому что он блядь медленный пиздец, и я ебал это.
Ну а вообще мне эликсир реально заходит
тот чел который писал про перекат с rust на elixir
Я вкатывался в Rust, но когда ты делаешь некоторые вещи на этом языке как например веб разработка то это боль в жопе.
Надо ВКАТИТЬСЯ, а не вкатываться. Глагол совершенного вида, понимаешь?
Какие шансы закатиться у недоджуна, знаю haskell на базовом уровне, есть опыт в пару месяцев на python/django или такие не нужны и ждут мидлов+?
Джуны нужны, но ты ведь не джун еще. Хотя бы год-полтора если бы было опыта разработки на питоне/руби, то можно было бы найти. Мы недавно искали разработчика. Если раньше было легко найти эрлангиста с опытом, то сейчас вообще никого. Решали брать даже джунов/мидлов, просто толковых, с опытом на каком-нибудь питоне/руби, которые с энтузиазмом хотели бы освоить эликсир. В итоге взяли джуна с полтора года опытом на питоне, пока справляется.
>>2218448
Ну и если ты все таки подучишь прежде эрланг/эликсир, напишешь какие-нибудь простенькие пет проекты или полезную библиотеку (что вообще не сложно, так как библиотек для Эликсира часто не хватает и все пишут свое), то это сразу выделит тебя.
Поглядываю из рубей одним глазком
Чаще всего веб, апи сервисы, реже софт риалтайм. Rest-фреймворк только феникс, GQL фреймворк тулкит - Absinthe. Вообще, в языке не особо поощряются всякие фреймворки в классическом смысле, тот же феникс - просто набор миддлварей и макросов.
По-быстрому, максимум ты сможешь изучить его для чтения крешдампов. Чтобы понимать внутренне устройство кролика, нужно будет знать язык на хорошем уровне, а не только синтаксис, а это долго и ради такой задачи - проеб времени. К тому же, без реального опыта написания чего то ты все равно не сможешь понять всех ньюансов. Учить эрланг сейчас смысла нет, скоро на нем останется только рэббит, энжабер и всякое легаси. Так что проще разбираться с рэббитом как с чёрным ящиком, он относительно популярный, не думаю что у тебя там какие-то уникальные ошибки, с которыми никто никогда не сталкивался.
А можешь тогда подсказать материалов по изучению рэбита? большинство, что советуют индетрнете это про то как к нему коннекторы а разных языках писать, а не про внутреннее устройство
github и читать исходный код. Иначе просто гуглить ошибки.
>github и читать исходный код
Для этого нужно эрланг хорошо знать
https://www.youtube.com/watch?v=YVrfGUgDVhs
https://github.com/rabbitmq/internals
+ руководство "как я перестал беспокоиться и начал гуглить"
Никто не хочет объединиться и что нибудь сделать совместо?
Например telegram tdlib
Какие шансы вкатиться, если android kotlin middle dev ?
Не хочется в руби лезть. Здесь мне нравятся идеи, а беком не занимался. Ну, занимался, обычный туду лист условно, но на этом все.
>если android kotlin middle dev
А зачем? Если ты не пиздабол конечно. У вас же и так там все хорошо на рын очке.
Мимно-5-лет-коммерческих-динамических-оперденей-на-эликсире-и-эрланге
А если серьезно хочешь, то ничего не мешает - если ты мидл на этих ваших jvm, то ты, очевидно, не совсем дебил и сможешь освоить любой нормальный ЯП. Из плюсов - если есть более года-двух опыта работы на elixir/erlang, то эйчары прямо таки ебут вакансиями (пишут даже на ватсап), потому что таких людей в снг очень мало, а компаниям они очень нужны. У меня только на email больше 20 предложений с середины января по сегодня, если не отвечаю на письма, то еще по 3 раза пишут и просят хотя бы явно ответить отказом
>Из плюсов - если есть более года-двух опыта работы на elixir/erlang,
Ну вообще, это в любом языке от 1-2 года опыта, мне тоже долбят еверидей.
>А зачем? Если ты не пиздабол конечно. У вас же и так там все хорошо на рын очке.
У каждого, кто не отбитый, будет все хорошо. Тут вопрос в интересности больше. Да и в макакуконтору не возьмут, это вакансии для стабильный компаний у который сформировался стек, я так полагаю. Так что, все еще размышляю.
>Мимно-5-лет-коммерческих-динамических-оперденей-на-эликсире-и-эрланге
Расскажешь стори? Как впечатления от работы и в целом атмосфера.
Да хз что рассказывать. Радует, что писать приходится что-то отличное от обычного бэкенда под crud, задачи обычно посложнее и поинтересней. Коммьюнити нормальное, не знаю как сейчас, а раньше на форуме мог сам создатель эликсира на вопросы отвечать и, если требуется, оперативно делать багфиксы
Спасибо за ответ, хоть и краткий)
А какие +- задачи в целом ? Если не круд обычный.
Авторы вообще развивают язык? Судя по конференциям и статьям, сейчас язык просто находится в поддержке и у них пустой беклог. Идеи кончились?
https://youtu.be/_Bnhwv9JLzs?t=2696
В прошлом релизе (2 месяца назад) очень ускорили время компиляции, добавили нативную поддержку xref и Code.Fragment - полезную для редакторов.
Сейчас продолжают работать над интеграцией с OTP-24, логгером и просто добавляют новые функции, улучшают матчинг и т.д.
https://github.com/elixir-lang/elixir/blob/c6e18cd17bc5911afe1422ba3247a37cbbab58e6/CHANGELOG.md
Типа того. Был план что надо в языке, все сделали по плану. Красиво же
Elixir is done +- в 2018
Мой первый пинг понг, конечно можно легче без дефмодулей. Но все же.
Elixir is a just a curtain and behind it there is evil erlang.
Сейчас познакомился с самим генсервером.
Вообще интересно конечно.
Сколько зп в эликсире?
Он используется на беке и IoT ?
Еще кринжовей, это найти elixir desktop с 700 звездами. Это полнейшая дичь вообще, люди комитят в либы, которые вообще не нужны для эликсира
Ну что двачик, ещё не на эликсире?
мимо 400к
Чекай выше сообщение. Используется и в бэке (https://hexdocs.pm/phoenix) и в IoT (https://hexdocs.pm/nerves)
Я лично знаю чувака, который делает elixir-desktop, и ему банально нужно было запилить максимально просто десктоп UI клиент к его сервисам для распределенной хуйни. Он это делает под себя и для себя, причём даже готов платить за разработку этой хуйни
А LiveView, как уже 1000 раз до меня говорили, это решение для маленьких и локальных админок для, например, IoT или какой-то домашней хуйни. Хотя на LiveView делают и большие сайты, чекай https://cars.com
Боже мой, ты прямо как с Обнуляй репостишь. Типа, если на английском цитатка, то она сразу правильная и в неё нужно верить.
Залогинься
> Хотя на LiveView делают и большие сайты, чекай https://cars.com
Не знаю. Ты нажимаешь обновить - отправляется запрос на бек - строится верстка и выплевывается - и на этой огромной операции фронт показывает лоадер.
С этим примером можно много юз кейсов придумать, с которыми стрельнешь себе ногу. Что уж говорить об анимациях и прочего. Все еще не понимаю.
И чтобы этот бэк запускал несколько nodejs процессорв (игроговно) со всеми настройками.
И нужно ли тебе вообще элик для запуска несколько процессоров?
У тебя ерланговская ВМ комфортно себя чувствует с 100к - 280кк зелеными тредами. А ты хочешь 3-4 зеленых запускать. Надо ли оно тебе вообще, мб возьми другой язык (но если хочешь Fault tolerance то welcome)
{x * y, "Jeez, come on!"}
end
Почему нельзя было сделать так?
А бд своей нет типо? Так-то можно и постгресс на n репликаторов с бизнес-логикой поднять.
С элексиром это будет проще или чо?
>>2289228
> И нужно ли тебе вообще элик для запуска несколько процессоров?
Это на одном инстансе только. Инстансов может и сотня быть. Да и игровые сервера сами себя не поднимут.
Впринципе оно нормально и на обычном пистоне/жс будет работать и подниматься (вместе с репликаторами и постгрессом), но хочется чего-то новенького.
> А ты хочешь 3-4 зеленых запускать.
Так это игровые сервера только, по факту самое главное. Там остальные приложения могут и под 100к процессов пернуть, если игроков зайдёт дохуя.
Так понимаю именно для этого мне элексир нужен? Чтобы пердеть нормально процессами и иметь годные пробросы до бд и кэшэй?
Мертвый?
нужно ли дрочить erlang ?
Нет. Если знаешь elixir, то, считай, что и erlang знаешь, останется только нюансы синтаксиса запомнить и всё.
очень понравился DSL, можно писать вообще что угодно https://www.youtube.com/watch?v=xj6yNzcGlEE
Зависит от того, с чем собираешься работать. Если планируется типичная круд хуйня с парочкой фоновых задач в Oban'е и капелькой асинхронности через Task, то не нужно.
Но если какой-то реалтайм проект с massive concurrency, то нужно, но не сам язык (хотя он очень простой и минималистичный, хоть и непривычный, потому что пролог) с выражениями и прочим, а OTP, процессы, BEAM и так далее. Поскольку без понимания всего этого кора и принципов архитектуры приложений на этой платформе шанс поесть говна почти 100%.
Лично я на собесах смотрю на какой проект человека хайрят, если на типичную апи хуйню почти без риалтайма, то спрашиваю только Elixir/Ecto/Phoenix/Absinthe и минимум по OTP, а если на реалтайм, то больше будем пиздеть про цепочки процессов, деревья супервизоров, ньюансы генсерверов и так далее.
Может потому что в языке динамическая анонимная типизация и многие не пишут спеки? А так пришлось бы всем писать.
>то больше будем пиздеть про цепочки процессов, деревья супервизоров, ньюансы генсерверов и так далее.
Но нахуя тут нужен эликсир? Никак понять не могу. Всё то же самое можно хоть на ноде сделать, похуй вообще будет. В чем суть-то нахой??777
Вот например, нормально ли распределённая бд? В чем преимущества эликсира тут? Есть какие-то высокопроизводительные решения с бд и меморизацией? Готовые ништяки с FoundationDB есть?
Или, может, эликсир работает тупо как распределённый орекстратор, который не обсирается и не падает?
>Вот например, нормально ли будет пердолить распределённую бд через эликсир?
слоуфикс
>Но нахуя тут нужен эликсир? Никак понять не могу. Всё то же самое можно хоть на ноде сделать, похуй вообще будет. В чем суть-то нахой??777
Потрудился бы хоть почтитать про elixir/erlang
>Вот например, нормально ли будет пердолить распределённую бд через эликсир?
Нормально, в erlang тащемта уже есть https://ru.wikipedia.org/wiki/Mnesia
Нормально будет пилить любую distributed/fault tolerant хуйню
Это можно на любом языке сделать, если настроить внешний супервизор и каналы коммуникации между сервисами. Единственное отличие элексиров/эрлангов в том, что там это встроенно в язык. Однако, гораздо легче найти программиста, который знает кубер/кафку/кролика и т.д. чем эрлангиста/элексириста. Единственную реальную вакуху, которую тут запруфали это телеком, для которого эти языки и были собственно созданы.
>Потрудился бы хоть почтитать про elixir/erlang
Да я писал даже на нём мелкие пердоли и апишечку не написал в итоге, кек
Кросиво, увожаемо.
> Нормально, в erlang тащемта уже есть https://ru.wikipedia.org/wiki/Mnesia
Разве она не оче слоу? Нужна относительно быстрая бд, тащемта я с постгресса хочу слезть на FoundationDB только из-за этого.
Но вообще можно всё быстрое отправить в отдельные процессы. Но ебать там сложность и кол-во языков получается.
> Нормально будет пилить любую distributed/fault tolerant хуйню
Что-то тут смущает меня, никак не могу понять что.
Возможно ли что эликсир/ерланг очень слоу (даже хуже ноды) и мне придётся всякие рейтинговые подборы перепердолить в отдельных С процессах?
Причем здесь динамическая типизация и явный показ типов? В питоне тоже динамическая типизация, братишка.
Но я и без тебя понял и нашел ответ, ведь ты не можешь ответить на вопрос. Здесь достаточно свой макрос сделать и все.
Одни ищут причины использовать Х, другие просто бегут и используют то, что надо. Остуди жопу, чмо.
Откуда ты знаешь что "то, что надо" действительно нужно использовать? Подбор стэка один из самых геморойных этапов разработки и довольно долгий.
То есть ты признался, что элексир это булщит для скучающих программистов, которые хотят выебнутся и никакие предварительные расчеты проводить не нужно
А ты действительно занимаешься чем-то таким высоконагруженным или занимаешься преждевременной оптимизацией на двачах?
Используй любую стороннюю СУБД, которая тебе нравится, а на elixir хуярить бизнес-логику, которая с этой СУБД конкурентно и откозоустойчиво взаимодействует, ёпта.
>А ты действительно занимаешься чем-то таким высоконагруженным или занимаешься преждевременной оптимизацией на двачах?
Ну я имел дело в прошлом с высоконагруженным игроговном, в пике до 2кк/сек было, долбоеб неудачно рекламу разместил. На ноде, пистоне, цитоне и с++. Работало как-то, поднималось автоматически.
Сейчас занимаюсь преждевременной оптимизацией, потому что делаю фреймворк для потенцивально высоконагруженного игроговна. а сейчас вообще застрял на обновлением видеобуфера на клиенте, ебать, как мне функции-то нормально отправлять в проход кадра
> Используй любую стороннюю СУБД, которая тебе нравится, а на elixir хуярить бизнес-логику, которая с этой СУБД конкурентно и откозоустойчиво взаимодействует, ёпта.
Вот тут проблемы в игроговне с разделением бизнес-логики и высоконагруженной хуиты. Архитектура непонятная нихуя. Видимо для игроговна эликсир вообще лучше не использовать?
Мне похую на тебя браток, и на то, как ты воспринимаешь инфу.
Если у тебя какой-то онлайновый игровой движок, то не подходит, так как элексир это про мягкий риалтайм хотя если обновление данных построено на эвентах, как hots...
Не, игровой движок отдельно идёт, он на ноде и как отдельный процесс стартует, оно в любом случае отдельно. Речь скорее про оркестровку этими процессорами на десятках серверов по всему миру и отправка туда инфы всякой. Плюс обычный социальный набор - друзья, сообщения, группы, оповещения и вся дата пользователя для игры.
Сейчас план прост как две копейки - кластеры постгресса.
И проблема тут в том что даже обычные действия и всяческий посыл говна на отдельные сервера должен происходить достаточно быстро.
На elixir пишут сервера для игроговна тоже, в panzerdog не так давно искали разработчиков: https://spb.hh.ru/vacancy/32702285
Wargaming тоже как-то искал
>На elixir пишут сервера для игроговна тоже
>присоединиться к команде Premium Shop
Это мягко говоря не про сам игровой сервер, лол.
Для магазинчика-то самое то.
В другой вакансии:
>Разработка нового игрового функционала и развитие существующего на стороне мета-сервера (внутриигровые покупки, матчмейкинг, турниры, кланы, социальные функции, квестовая система и тд)
Ну хуй знает. Выглядит конечно заебок. Готовые решения есть какие вообще?
Хз, что ты подразумеваешь под готовым решением. "Установите и настройте рабочий игровой сервер из коробки" - ничего такого, само собой, нет. Есть веб фреймворк со всякими pubsub хуйнями (phoenix), есть встроенный в язык фреймворк для динамической хуеты (OTP) - обмазывайся сам как хочешь.
Комиты которые мы заслужили. Fix docs, update docs, Fix indentation
>Хз, что ты подразумеваешь под готовым решением.
Да тоже хуй знает. Скорее я пытаюсь найти отговорки чтобы не использовать ерланг.
Он слишком приторный. Как приторная любовь, или что-то такое, приторно-сладкое. Слишком хороший для всей это оркестрации соединений, а значит там будет какая-то большая-большая проблема. Сложность разработки и создания? Хз.
Это да, видимо придется просто кластеры хуярить или вроде того. а потом набирать эликсирщиков чтобы переписали нерабочий говнокод на эликсир
Ну это-то проще всего планирую заработать овердохуя на относительно новых нишах, ух влажно потекло по штанине
Просто он слишком приторный. Слишком хороший.
для этого есть удаленка
>>2292881
>Слишком хороший для всей это оркестрации соединений, а значит там будет какая-то большая-большая проблема. Сложность разработки и создания? Хз.
Честно, вы боитесь что то попробовать. Что за страх у всех. Взял да и попробовал . В чем проблема?
> Взял да и попробовал .
Ну так-то нельзя просто взять и попробовать два раза написать бизнес-логику, если эликсир не зайдёт. Это тонны говнокода.
> В чем проблема?
Хз, хз. Что-то из разряда и иррационального. По крайней мере у меня.
>(внутриигровые покупки, матчмейкинг, турниры, кланы, социальные функции, квестовая система и тд)
Т.е. к самому игровому серверу (который именно обрабатывает ввод и отдаёт апдейты юзеру) вторая вакансия имеет только косвенное отношение.
>Это тонны говнокода.
А нахуя тебе высирать тонны кода, когда тебе всего-то надо заебашить какой нибудь MVP и подумать насколько оно применимо?
>для этого есть удаленка
Аргумент говна, конечно.
Что она меняет-то? Вот нашёл ты за пол года на рынке 3 программиста на эликсире, завтра какой нибудь банк/стартап поднявший раунд инвестиций/буржуйская галера зашедшая на местный рынок с $ зп начнёт хайрить — они убегут одним днём и сиди ищи ещё пол года.
К игровому серверу да, игровые сервера полностью на с/с++ делают, в крайнем случае js, как моё браузерное говно. Ну или на жабе, ололо
Вот все эти игровые покупки, внутриигровые сообщения, сервера, матчмейкинг, социалка - бизнеслогика игроговна. И теоретически всякие эликсиры тут мастхэв, потому что куча пользователей и кучу параметров.
Но репликация и кластеры позволяют вполне неплохо балансировать огромные нагрузки, так еще и бизнеслогику можно на с++ писать, шобы оно быстрое было и утилизировать мощности серверов нормально. Буквально десяток серверов с бд и бизнес-логикой на весь мир и локальные игровые сервера позволяют балансировать десятки миллионов пользователей.
Т.е. вероятнее всего эликсир в игроговне будет служить тупо оркестратором с++ либ, вроде typesense, матчмейкеров, серверов, бд, кэшэй.
Может, эликсир полезен будет когда кол-во серверов будет измеряться в стойках, а не в штуках? Хуй знает.
Но всё равно приторно.
>>2292982
Два проекта сразу в прод делаю, должно работать еще вчера. Не получится взять и две бизнеслогики напердолить.
Бля, да если у тебя реально сервера на nodejs, то с elixir ты точно не соснешь. Аналогичный сервер на elixir (с нормальным concurrency и отказоустойчивостью) дадут вашей ноде за щеку раз 100, несмотря на то, что нода быстрее работает на бумаге. Не говоря уже о том, насколько приятней все это будет разрабатывать и дебажить.
Всерьез считаю полными опидоревшими безумцами людей, которые додумываются бэкенд на js писать
>Аналогичный сервер на elixir (с нормальным concurrency и отказоустойчивостью) дадут вашей ноде за щеку раз 100, несмотря на то, что нода быстрее работает на бумаге
В контексте игрового сервера не даст, потому что там прежде всего нужна сырая производительность в однопотоке плюс числодробилки всякие, и ничего из этого сильной стороной эликсира не является, и нода на выдроченном на производительность V8 надает ему за щеку только так. Игровой сервер - это не распределенная система, а один поток, который должен быстро-быстро хуярить тики.
>Два проекта сразу в прод делаю, должно работать еще вчера. Не получится взять и две бизнеслогики напердолить.
Тогда пиздуй кранчить как нормальный гейдев, хули ты тут сидишь тебе прямо сейчас вкат в новые технологии вот вообще не всрался, не задумывался об этом?
Даже если элексир подойдёт на 1000% — ты обосрёшься.
Бизнеслогика на питоне, частично на ноде и с++. Нода действительно быстро работает, коннекты тоже норм держит, потому что сетевуха на с++.
>>2293118
Игровой сервер это нода и с++ либы, речь про именно игровой сервер не идёт. Тут ежу понятно что никакие эликсиры не справятся. Оно по сути отдельной жизнью живёт вообще, взаимодействует остальными серверами только на старте/конце, загружая/отгружая крупные массивы данных изредка.
Проблема вся в том что остальные сервисы (матчмейкеры, социалка, магазины) тоже требуют относительной быстроты, плюс на игровые сервера нужно крупные куски данных лить часто, быстро.
>>2293135
>Тогда пиздуй кранчить как нормальный гейдев, хули ты тут сидишь
Нужно пиздовать думать, ето да. Достаточно прохладился.
>тебе прямо сейчас вкат в новые технологии вот вообще не всрался, не задумывался об этом?
Нет на самом деле, не задумывался. Ты прав, нахуй не всрался, нахуй я вообще эликсир взял тестить и проектировать. Кажется потому что репликация не решает всех проблем, не помню где был затык уже, нужно разобраться блокноты.
>Даже если элексир подойдёт на 1000% — ты обосрёшься.
Всё так.
>Проблема вся в том что остальные сервисы (матчмейкеры, социалка, магазины) тоже требуют относительной быстроты, плюс на игровые сервера нужно крупные куски данных лить часто, быстро.
Это все можно писать на любом веб-фреймворке, потому что это по сути обычная веб апиха, и тут стандартные джанга с рельсами подойдут гораздо лучше эликсира хотя бы просто из-за популярности и простоты.
Джанга с рельсами, жиденько пукнув, умрут после первой же тысячи rps.
Во-первых не умрут, во-вторых это прежде всего оптимизируется количеством серверов и лоад балансером, говорить как ты говоришь "у нас будет много запросов, поэтому оптимизируем на уровне языка сразу же и пишем на си, чтобы один инстанс вместо одной тысячи rps хенделил три" может только шизик. Высоконагруженные веб-сервера спокойно пишутся на чем угодно, там есть миллион способ оптимизации, которые не требуют переписывания всего проекта на другой язык.
На плюсы логику переписывают чтобы не закупать серверные стойки вместо одного сервера. Иногда выгода в 20раз получается.
И вместо 1к rps он будет 11-18к брать, а не три.
Что-то более-менее сложное, ещё и под хайлоад, на крестах пилить это адъ и пиздецъ. Ты утонешь потом в ловле багов и поддержке этой хуеты, если писать нормально по "C++ way". А если без крестовых маразмов, то проще сразу пиздон или руби взять или что там ещё высокоуровневое в живых осталось.
> Иногда выгода в 20раз получается.
А на асме в 50. Но есть нюанс.
Да нет там нюанса, в гейдеве плюсисты хоть и в основном посредственные — один из преобладающих видов хомо анальникуса.
Ну гейдев понятно - на стабильность срать, хайлоада нет, главное чтобы относительно быстро шуршало и на так задротно писать как на чистом асме и winapi. На второй фейсбук или ютуб этот подход перенести малой кровью не получится.
Ну пора уж принять, что большинство проблем "плохих" языков решаются апгрейдом железа.
Багов будет куча в любом случае, но не из-за языка. Если его не будет писать 2,5 ждуна, кек.
>то проще сразу пиздон или руби взять или что там ещё высокоуровневое в живых осталось.
Для всего, что не связано непосредственно с геймплеем (если не говорить про браузерки/пошаговые стратегии) так и делают.
>>2293501
>На второй фейсбук или ютуб этот подход перенести малой кровью не получится.
В фейсбуке и ютубе этих плюсов не то чтобы сильно меньше. Тут уже вопрос выгоды бизнеса.
>Ну пора уж принять, что большинство проблем "плохих" языков решаются апгрейдом железа.
Так никто и не спорит, речь шла про игори.
Нормально всё, пилишь на императивщине и всё. Можно и на си писать отдельные либы логики.
Конечно часть логики на пистоне, жабе, шарпе и ноде пишут, если это не критично.
>>2293465
Пчел, ты не понимаешь уровень нагрузок.
С одной неудачной рекламной компании может 2кк игроков завалиться в раз. Или если новость об игроговне запостит кто. Всё это нужно моментально обработать и выдать без промедлений клиентам, по этому довольно много логики написано именно на плюсах.
>>2293501
> Ну гейдев понятно - на стабильность срать, хайлоада нет,
Ну вообще-то нет. Там и хайлоад есть и стабильность нужна. Стабильность через балансеры, да.
Ты серьезно пытаешься сказать, что единственный способ написать хайлоад веб-приложение - это писать его на плюсах? И что на руби, питон, жсе хайлоада нет и всякие бейскампы просто падают при большой нагрузке, ведь они же не на си написаны? Ты ебанутый?
Чел, что за шизофрению ты выдумал вообще? Этого же буквально нет в моём посте, ты придумал всё. Таблетки выпей.
Речь об отдельных либах логики на плюсах, а не о приложении.
Каких отдельных либах, если в ветке обсуждения идет разговор о том, на чем писать сервер под хайлоад? И да, вставка низкоуровневого кода исключительно ради оптимизации - это пиздец редкость в вебе, а не некая распространенная практика, как ты подразумеваешь. Обычно с головой хватает оптимизации через переписывание обычного говнокода, никому не нужен еще и лишний говнокод на си.
В вебе обычно кресты заканчиваются на веб-сервере и интерпретаторе VHLL-хуеты. Бизнес-логику на крестах для веба никто не пишет. Ну может что-то штучно-уникально-самойстийное для банков и тп, хотя у банков фетиш на джаву с 90ых ещё.
Чел, сервер не обязательно означает стандартное веб приложение, которому надо сходить в базу и плюнуть ответ.
Тебе уже 10 сообщений подряд втирают, что речь не про написание сайта идёт и с тобой никто не спорит.
>>2293656
У «всяких бейзкампов» принципиально другая модель взаимодействия, нет необходимости в сколько нибудь риалтаймовом взаимодействии, да и просто экономика бьётся.
А вот у всякой фри ту плей мультиплеер залупы это всё не так от слова совсем.
>Чел, сервер не обязательно означает стандартное веб приложение, которому надо сходить в базу и плюнуть ответ.
В контексте разговора - означает, веб-сервер для игрового магазина или лаунчера занимается именно стандартными для среднего сайта вещами, а не дохуя трейдинговым риалтаймом.
>Каких отдельных либах, если в ветке обсуждения идет разговор о том, на чем писать сервер под хайлоад?
Что значит "на чем писать сервер"? Ты имеешь ввиду либу типо asio? Или что? Сервер пишется на нескольких языках, которые включают и системные либы, сокеты, либы матана, либы компрессии и многое другое. Почти все эти либы на плюсах написаны.
> И да, вставка низкоуровневого кода исключительно ради оптимизации - это пиздец редкость в вебе, а не некая распространенная практика
У тебя просто веб заканчивается сайтоговном всяким уровня тудушек, ты берешь обычные говнозапросы и никакую нагруженную логику не юзаешь. Потребуется какая-нибудь многомерная интерполяция - соснёшь. Лично мне она требуется два раза целых, лол
>>2293680
> Бизнес-логику на крестах для веба никто не пишет.
Смотря что есть бизнес-логика. Крайне нечёткое понятие.
Кажется в этом итт треде под бизнес-логикой понимают вообще всю серверную логику. Но в реальности это работает только на уровне говянного магазинчика и тудушек.
>Сервер пишется на нескольких языках
Не пишется, ты подменяешь понятия. Тот факт, что у тебя под капотом руби дергает какую-то системную си-либу для того чтобы сложить хуй с залупой, не превращает твой написанный на руби проект в "написанный на нескольких языках".
>Не пишется, ты подменяешь понятия.
Пишется. Ну по крайней мере в игроговне и высоконагруженной хуйне всякой. Вообще хз как там в сайтоёбстве на самом деле.
>Тот факт, что у тебя под капотом руби дергает какую-то системную си-либу для того чтобы сложить хуй с залупой, не превращает твой написанный на руби проект в "написанный на нескольких языках".
Т.е. либа в таком случае исключается из понятия "сервер", правильно? А если либа как CGI скрипт подключается, то как тогда? А если руби 49%, а CGI-скриптов на си 51%, то как тогда? А если конкретный запрос обслуживает только CGI скрипт на си, считается ли это сервером на си?
>Т.е. либа в таком случае исключается из понятия "сервер", правильно?
Из понятия "написанный тобой сервер" исключается все, что ты не писал, в том числе биндинги в другие языки под капотом твоего языка, операционная система и прочее-прочее. Вопрос в чем?
> Из понятия "написанный тобой сервер" исключается все, что ты не писал
Хорошо тогда, 30-40% года у меня на плюсах написано для сервера, особенно прокладки под бд, балансеры и несколько Qpid.
> Вопрос в чем?
Ты почему таблетки не выпил, хайлодаер на руби?
>Хорошо тогда, 30-40% года у меня на плюсах написано для сервера
Поздравляю, только как это относится к твоему шизоидному заявлению о том, что без плюсов хайлоад невозможен?
А что лучше, вкатиться в эликсир и потом поработав выучить рельсы (я хочу только бек писать)
Или лучше в рельсы и потом в элик.
Мимо 3 года на ios сижу.
Рельсы очевидно, эликсир это чисто игрушка что-то новое попробовать, работать ты на нем вряд ли будешь, тем более в качестве джуна.
Но мне нравится элик и феникс, особенно то, что он компилируется и можно написать макрос с типами.
У тебя реально шиза, ты видишь то чего нет.
Нормальный хайлоад в игроговне, и прочем таком, невозможен без плюсов. Просто потому что это действительно хайлоад и процессов очень дохуя может стартовать и очень тяжелых. Например шмотки из магазинов должны копироваться на игровой сервер с разным коэффициентами, вместе с огромными запросами из бд.
На всяких сайтиках-магазинах и прочей хуйне хайлод можно и без плюсов, потому что плевать на задержки.
Сразу elixir. Если потом все равно собираешься в elixir, то руби только засрет тебе голову ООП-говновермишелью.
> засрет тебе голову ООП-говновермишелью
Поехавший.
В руби наверное единственном ООП сделан идеально, ну или близко к идеальному. Любой токен, любой результат любой функции можно через "." прохуячить миллионом методов, к результату ещё что-то применить... Это безумно удобно и легко писать. Если уж руби в чём-то обвинять, то в том что он слишом балует хуманов комфортом.
Согласен с ним.
Уже итак все языки засраны процедурным ООП. Один руби выживает. Ну и свифт.
>Например шмотки из магазинов должны копироваться на игровой сервер с разным коэффициентами
Это ничем не отличается от стандартной задачи по синхронизации данных между разными серверами, которая в обычном вебе возникает и решается на каждом шагу.
В таком хайлоаде она не решается сразу для 20к инстансов, которые стартанули одновременно или около того. И для каждого инстанса нужно перекинуть метра два чистых данных из бд, например, отработать по ним функциями, загнать в кэши и еще кучу хуйни сделать.
Ты просто не понимаешь какого уровня там хайлод работает и как он во времени распределён. Мало того что он нелинейный, так еще и ебанутый с ебанутыми массивами данных, тот же обоссаный матчмейкинг - просто пиздец без плюсов. В некоторых калпаниях берут отдельные стойки для матчмейкеров, неужели ты думаешь что там нет плюсов?
Еще раз, ты прав, всякие магазы пердолят на обычном вебговне и большее что-то там нинужно, хватает даже обычного рестапи. Но уже взаимодействие между бд, серверами и игровыми серверами приходится на плюсах пердолить.
>В таком хайлоаде она не решается сразу для 20к инстансов
Какие нахуй 20к инстансов, по которым ты там собрался шмотку одного игрока раскидывать, шиз?
>В некоторых калпаниях берут отдельные стойки для матчмейкеров, неужели ты думаешь что там нет плюсов?
Не вижу как отдельная стойка для чего-то автоматом дает возможность сделать вывод, что это что-то можно писать только на плюсах, иначе пиздец.
У тебя опять шизофрения протекает, придумал как какую-то шмотку куда-то перекидывает, лол. Таблеточки...
Так я не о том, что в руби плохой ООП, а о том, что если собираешься вкатываться в ФП, то лучше сразу с этого и начать, не захламляя голову ООП хуйней, которая там не пригодится
>Всё то же самое можно хоть на ноде сделат
Нельзя, очевидно. Вернее можно, можно хоть на пхп, если делать нехуй и сильно хочется говна навернуть.
>Или, может, эликсир работает тупо как распределённый орекстратор, который не обсирается и не падает?
Ну как бы Erlang/BEAM под хардкорный распределенный fault-tolerant с зиллионом соединений на каждом узле и создавался, изоляция, акторы, вмка со специальной моделью памяти, сделанная нормально вытесняющая многозадачность, авто-смп по ядрам изкоробки и все вот это. Elixir работает поверх Erlang/BEAMи соотвественно все это умеет.
>>2294501
>сделанная нормально вытесняющая многозадачность
А чем условный pthreads ненормален?
>Нельзя, очевидно.
Можно, просто это очень неприятно временами бывает.
> с зиллионом соединений на каждом узле и создавался, изоляция, акторы, вмка со специальной моделью памяти, сделанная нормально вытесняющая многозадачность, авто-смп по ядрам изкоробки и все вот это.
Давай проще. Вот у меня есть несколько групп серверов. Первая - бизнеслогика, магазины, сайты, тонны скриптов, несколько серверов. Вторая группа - кластер постгресса с ослом/ектедом. Третья - гейдев с сотнями геймсерверов на с++ и ноде.
Где тут ерланг будет? Можно ли сделать ерланг на ВСЕХ серверах сразу нахуй, чтобы без ослов и ектедов было, и соеденялся ерланг между серверами сам, поднимался сам, при нагрузке запускал кластеры сам, балансировал сам, да и геймсервера автоматически поднимались?
>Elixir работает поверх Erlang/BEAMи
Ну короче можно сразу на ерланге писать.
>>2294507
>Подписался на срач про хуйлоад сервер для геймдева
На самом деле вопрос серьезных технологий оказалось. Вспомнил почему решать это нужно под нагрузкой со своими серверами я обосрался на тестах
>лет через пять
Пили прямо сейчас.
Шизофреник, я тебе отвечаю на твой же пример из прошлого твоего поста. В голове больше двух предложений удержать не можешь, а табелтки надо кому-то другому пить?
Нет, шизоид, там такого не было. У тебя шизофрения и ты читать не можешь уже.
В смысле, блядь, не готов? Давай готовь нахуй.
Там в клиенте проблем больше на самом деле чем во всех серверных хуйнях вместе взятых.
Хотя если пердолить клиент на плюсах под десктоп и мобилки то нормально выйдет, но рынок браузерной АА-хуйни сам себя не освоит. а я ещё собираюсь свои клиенты с v8 и опенжл пилить, чтобы с браузера говнокод можно без модификаций в натив релизнуть
На чем делать-то будешь?
> Хотя если пердолить клиент на плюсах
Чи шо, я ещё пока не ебанутый, клиент пишу на человеческом VHLL на каком - не скажу, деанон. Сервер на нём же, хотя вот поглядываю в сторону элика.
VHLL
Мда. Много шума из ничего. Даже пошел погуглить что же это такое. Оказалось просто язык нейм. С таким же успехом можно в одну гребенку собрать то, что описывалось выше.
Да какой тут деанон, всем похуй.
Еслишо я пишу на webgl, js и хтмл клиент сейчас (гуй пока что только, ололо) + задел на рендер через потоки в своём собственном "браузере" - обсерверы на хтмл вешаю и архитектуру хитровыебанную делаю, должно получиться впринципе.
Тем, что треды - это shared state, а значит локи, гонки, отличие времени жизни треда от времени жизни данных гроб гроб кладбище пидор. Треды это большое зло, программировать на них что-то больше, чем на два потока - это лютая головная боль и байтоебство. В какой-то момент градус отчаянье сообщества дошел до такого уровня, что от них поголовно стали отказываться даже на лоулевеле если это было возможно в пользу однотредовых FSMов, из которых потом вышли все модные в нулевых движки на событиях типа ноды, торнадо, евентмашин и так далее. ФСМы конечно тоже хуйня, и не быстрые как треды, но все ещё не надежные, конкурентная многозадачность опять же, хуевая масштабируемость, но хотя бы shared state избежали, а это уже делает их лучше говнотредов, к тому же сраному интернет МагаЗину или говнобраузерке они не очень то нужны, а асинхронность все таки иметь хочется. В ФП были более удачные модели, тот же STM или фьючеры, но это все полумеры: STM - просто shared state сделанный правильно, то есть проблему не решает, а только сглаживает боли, E-стайл фьючеры идея годная, но fault-tolerance, особенно в распределённом среде, не обеспечивает и даже усложняет его достижение. Из более популярных альтернатив ещё были гринтреды, но до эрланговских процессов все равно не дотягивает, ну и опять же, полумеры без основательного решения проблемы. Из хорошей альтернативы есть разве что go-каналы, во-первых, CSP - достойная конкурентная модель (Хоар - гений, хули), во-вторых, даже запилили вытесняющую многозадачность (все равно более ограниченную, чем в BEAM). Жаль только язык получился какой-то goвнарский, ну и на практике быстро выясняется, что реализация всего этого какая-то поверхностная, во всяком случае для распределённой среды там нет ничего, то есть по дефолту подразумевается микросервисная архитектура и решение проблем взаимодействия сторонними инфраструктурных средствами, как обычно бывает, когда в инструментарии самой платформы для этого нет нихуя. То есть с таким же успехом можно было бы собрать узлы на питоне, соединив их с каким нибудь MQ для пабсаба, Redis Cluster и поставив вперед nginx как реверс прокси (особо упоротые нарки ещё и по ядрам это говно умудряются масштабировать, даже с каким то самописным супервайзингом) - то есть криво собрать наколенке то, что в эрланге ещё 20 лет назад сразу шло искоробки и бесплатно (кроме разве что распределённого in-memory хранилища, потому что мнезия для широких задач не канает).
Вот и получается, что альтернативы у BEAM в плане удобства для такой разработки и чтоб со встроенными средствами для отказоустойчивости по сей день нет, да и вообще приятно, когда в языке/платформе сразу есть все нужные примитивы для программирования систем, которые удобно моделируется через взаимодействия акторов и не нужно ебать себе мозги низкоуровневым говнищем. Причём поддержка платформы тут главное, я вот с другими актор-фреймворками работал, Акка и Аккадотнет и это пиздец, понимаю почему скалисты сьебывают на каты, а все потому что одно дело когда у тебя сразу есть специальная вмка и щедулер, а другое дело когда ты пытаешься акторы натянуть поверх всяких говнарских жвм тредпулов.
tl;dr: вместо того чтоб читать многобуков на форуме анонимных испердов, просто ставишь ерланг/еликсир и пробуешь все сам, за пару недель все поймёшь. Вспомнил классику:
С эрлангом намного проще, каждый кто написал 10 строк на Эрланге врубается сразу и пишет у себя в резюме Distributed Systems, High-Load Projects, Pi-calculus и Concurrency Master. После Эрланга становися сразу ясно почему Akka, Okku, Quazar, Kilim, Go, Итераты вместе с Клауд Хаскелем сосут прричмокивая. То где другим языкам нужно написать 100 кб кода для определения стратегии yied в скедюлер (memory/message threshold), в Эрланге делает одним условием
https://topbloger.livejournal.com/14771076.html
Жаль максим ебнулся мозгами и читать его теперь физически сложно, хотя это и тогда было на грани, но в этом и был шарм, а теперь это просто шиза, хотя иногда для получения живительного заряда шизокоетента открываю его tw
>Тем, что треды - это shared state, а значит локи, гонки, отличие времени жизни треда от времени жизни данных гроб гроб кладбище пидор.
Но ведь это решается просто кастомным семафором, не?
Да, бро, а ещё мьютексом, спинлком и критическими секциями. Ты же пынямаешь, что всё это дедовское байтоебское control-flow говноедство в более менее большой программе ни к чему хорошему не приводит. Одно дело когда ты там какой лоулевел пилишь в спартанских условиях, никаких удобств не предусмотрено и единственный вариант сделать задачу - это заплатить сотнями литров крови разорванных срак и зилионнами человеко-часов несчастных рабов байтоебышей вьебанных в отладку и тестирование. Ну типа лет 30-40 назад софт только так и разрабатывался, но сейчас так не принято, особенно если есть альтернативы. Раньше альтернатив не было, был выбор сосать на быстрых тредах, или не сосать на медленном FSM, и как я уже сказал, большинство выбирало не сосать, то есть
A Computer is a state machine. Threads are for people who can't program state machines
(c) Alan Cox
было плюс-минус позиция большинства, уж сильно жопа от тредов болела, несмотря на всю смазку в виде мьютексом-семафоров.
Правда позже реальность стала вносить свои коррективы в виде появления многоядерный процов и распределённых систем, и сидеть на ФСМах осталось возможным только в интернет магазинах, и говнобраузерках. Правда некоторые упоротые и LDAP сервера на ноде пишут, если долго мучатся можно все что угодно на чем угодно наговнякать, вопрос времени, боли и главное - поддержки этого говна.
> в более менее большой программе ни к чему хорошему не приводит.
Да, приходится раскидывать приоритеты всякие, неприятно. Но у меня приоритеты были конечные и их мало, так что терпимо.
> человеко-часов несчастных рабов байтоебышей вьебанных в отладку и тестирование
> Раньше альтернатив не было, был выбор сосать на быстрых тредах, или не сосать на медленном FSM, и как я уже сказал, большинство выбирало не сосать, то есть
У меня есть говняшка в стиле ECS и data-driven. Оно же просто работает, нормально работает, оче быстро, никаких проблем не вижу вообще, треды мутятся, ядра крутятся, могу в 240 герц укладываться на больших объемах. Теоретически можно fastcgi прикрутить, но я уже блюю от сложности. В прод не спускал, но должно нормально работать, можно сколько угодно ядер пускать на данные приходящие.
Как это вообще в ерланге-то работает? Неужели есть решение более производительное?
> конкурентная многозадачность
Дыкить ивентовые движки - это кооперативная многозадачность же.
Функциональнй программист М. Сохацкий стал бандеровцем:
https://twitter.com/infinitystack
Что грозит этому гуру Эрланга и Хаскелля, когда наши танки въедут в Киев?
Да при чем тут танки, ноль информации в твоих каментах.
Такое ощущение что ты перед кем-то выйобуешься.
Передо мной не нужно, для меня ты никто.
Помянем. А вот был бы императивщиком - другое бы дело было!
Rust лучше. И быстрее.
Почему?
Язык же один из самых лёгких и с одним простым фреймворком, в который всё включено
Здравствуйте!
Я - Elixir разработчик.
Это моя профессия.
Так сложилось исторически.
Когда-то я разработал Erlang.
Теперь это язык поддерживающий параллельные легковесные процессы и асинхронность.
Теперь на нём удобно разрабатывать распределённые системы.
Теперь на нём написан RabbitMQ.
Я разработал OTP.
Этот фреймворк я применил про разработке огромного разнообразия высоконадёжного телекоммуникационного оборудования.
OTP стала неотъемлемой частью экосистемы Erlang.
Я разработал BEAM и ERTS.
Вместе они позволяют коду на Erlang эффективно распараллеливаться и надёжно выполняться на разных узлах распределённой системы.
Я обогатил Erlang метапрограммированием и полиморфизмом создав новый язык Elixir, который можно применять везде!
Я создал Phoenix.
Фреймворк с отличной производительность и масштабированием объединяющей в себе всё необходимое для веб разработки.
Да, я - Elixir разработчик!
И я устал извиняться за это...
Я разработчик по праву рождения.
Я проектирую и имплементирую.
Бойтесь!
Заебали эти эрлангисты, хорошо что я в рассылке не отвечал, а то хотел было! Фух свят свят свят. НАХУЙ НАХУЙ.
Вцелом так то мне эти ебанаты похуй, я ж не буду ползать на коленах чтоб на N2O писали, так в жопу их, пошли все нахуй кто на эрланге пишет.
Как бы обидно для многих пердолей это не звучало, но распространенность технологии решает хайп и возможность перетечь в них из других областей, достаточно на JS посмотреть.
>«Решение использовать готовый язык вместо изобретения своего никаким образом не зависело от меня. Установка, поступившая с самых верхов, звучала так: “Язык должен выглядеть как Java”. Это сразу отбросило Perl, Python и Tcl вместе со Scheme. Позже, в 1996 году, к нам зашёл Джон Оустерхаут, чтобы показать Tk и посокрушаться по поводу упущенной возможности для Tcl. Я не горжусь, но я счастлив, что я выбрал в качестве основных ингредиентов функции первого класса по подобию Scheme и прототипное программирование Self. Влияние Java, особенно баги с датами в 2000 году и чувствительность к регистру, стало досадным недоразумением.» — Brendan Eich's blog: Popularity
>Хотя создание синтаксиса, максимально близкого к Java, не было основной идеей JavaScript, рынок внёс свои коррективы. Возможно, для решения определённых задач больше подошёл бы другой синтаксис, однако благодаря использованию всем знакомого синтаксиса JavaScript с лёгкостью набрал популярность.
Какие подводные камни?
Вот что случается, когда кабанчикам позволяют принимать технические решения.
И оно выстрелило, а так была бы никому не нужная хуетень с 2.5 шизами, которые спорят за всякие гомоиконности, но при этом промышленно не пишут на своем любимом языке. Программисты это в первую очередь обслуга бизнеса, все остальное только для борщехлебов и всяких академических кругов.
Ну ничё, скоро в богоспасаемой федерации опустится железный занавес, начнётся совочек 2.0 и за бизнес снова станут сажать, посмотрим, как вы тогда покукарекаете, бизнесмены ёбаные.
А всяких лиспов и эрлангов тоже не будет, только сишка и делфи, как диды
Что партия скажет, то и будет. Не твоего ума дело государевы вопросы решать.
а флайио как сервис?
От всех жемов с аасами бошка пухнет
Нужен бесплатный слиплесс инстанс под пару скраперов с веб и бот интерфейсами
Обязательно. Весь рантайм - эрланговский. Хочешь прогать - обязан знать, как работает эрланг vm.
>>2292329
Не, mnesia хуйня, никому не советую. Есть большой опыт работы с оной, и от этой хуйни больше проблем чем профита. Например, проебываются все данные, когда заканчивается место. Или, mnesia не умеет по дефолту в master-slave.
>>2311987
Да, я тоже люблю раст и есть говно
>>2312691
Добро пожаловать
>>2291558
Сложно сказать. С одной стороны, нужно уметь в рантайм, особенности компиляции, и прочие штуки. Но это скорее про BEAM (на эту тему советую почитать The Beam Book). А вот знать эрланг как язык нахуй не нужно, потому что читай ниже
>>2315365
Соглы, пересел с эликсира на эрланг за ахуенной зп и теперь очень сожалею. Ебанутый язык, с ебанутым синтаксисом и ебанутым комьюнити протобумеров, которые ну просто не могут даже допустить что в их любимом эрланге есть хоть какой-то недостаток. Типа, эти люди на серьёзных щщах защищают ебаные чарлисты.
>>2341005
Шансов мало, но за спрос денег не берут, так что откликайся на всё что видишь и пизди в резюме. Мой совет: запили проект в опенсорс, чтобы были пруфы того что ты реально могёшь в эликсир
>>2351060
Окей, мой сладкий
> mix escript.install hex livebook
Во-первых, в терминале делай reset и настрой правильно переменную TERM. Во-вторых, читай как правильно устанавливать https://livebook.dev/#install
> ты реально в этой стране хочешь остаться?
а где сейчас лучше?
в еуроппе с гхазом по 2к грина за куб и маргинальными нигерами с арабами или индусами повсюду, во франции белое ебло хуй встретишь
или в муррике где ГАЗОЛИН подорожал до 4 баксов за их маня-меру-объема и они уже начали смешные наклеички клеить на заправки, а когда он поднялся до 7 баксов там уже хотят устроить импичмент и это небацо сверхдержава, чуть более чем полностью состоящая из дешовых понтов и пузырей
а может в азии? ну в китае определенно лучше всего на планете, но туда не пускают, а среди вырожденцев сетстроебов делать нехуя, в корее дорого. вся остальная азия помойка и дикая пустош типа нашего замкада
куда уезжать то епта?
>>2367430
> в Грузии
вообще все ебанулись от своей нищеты и манямира. в армении скоро опять что то будет. в турции после путча все скатывается в говно.
Ты это к чему высрал, дорогой? Я просто спросил есть ли в Грузии кто из эликсирщиков, чтобы просто местный /soc/ устроить, пива попить да за эликсир попиздеть. Успокойся, дорогой
> чтобы просто местный /soc/ устроить
> спроси
> в
> /soc
даун
хотя это будет кринж инфа 95%
а я просто взял с тебя гринтекст. айсикью 60 блядь...
Нихуя себе ты злой. Что у тебя случилось? Как дела вообще?
а ты с какой целью интересуешься ?
Просто вдруг могу тебе помочь чем-нибудь, вдруг тебе надо просто выговориться. Ты не держи в себе, рассказывай, анон
помоги себе сам, тренируй стрессоустойчивость сука
а мне пиздежом на дваче не помоч.
Пока что есть несколько паттернов мультипоточной дрисни на ECS, кривые акторы без архитектуры и немного не менее кривых асинхронных функций. В идеале всё это должно работать вместе в одном фреймворке. Асинхронный, мультитредовый, ориентированный на данные фреймворк, который занимает примерно 150 строчек кода. Может ещё строчек 50 потрачу на всякие гарантии доставки сообщений, как-то читал что это очень и очень проблемно даже на одной машине случаются проблемсы.
Акторы будут запускать мультипоточные и мультитредовые системы, механизмы, отдельные функции, асинхронно и мультипоточно читать БД. Системы будут отсылать выпуки в акторы и общаться с серверами.
НУ И ЧТО СО МНОЙ НЕ ТАК?
если тебе делать нехуя напиши лучше для сраных крестов препроцессор избавляющий язык от всратого визуального шума ;{
если бы у меня был выбор я бы наверное выбрал ним и голову не ебал
но количество каложоров стремится к бесконечности, как и мои страдания в случае нужды
я как могу отодвигаю этот момент, но соломки лучше подстелить заранее
Бесмысленно. Ты вступил в секту ООП на плюсах, взяв в руки уеч. Либо ты волевым движением отказываешься от уеча и пилишь моё говно со мной (хотя я не умею в тиме работать, да и работать над такой сверхсложной хуйней в принципе), либо и дальше продолжаешь жрать уеч.
я никуда не вступал, мне похуй на уебищное ооп
твою портянку не читал, если ты не можешь лаконично излагать мысли - твой интеллект низок.
про свой движок у меня даже целый тред в гд есть, и сделать его нихуя не сложно, все уже давно изобретено
и самый умный вариант это пиздить у топов (т.е эпиков) но их мета язык с макросами это пиздец я даже думать о нем не хочу
поэтому для этой паскудной параши надо написать нормальный препроцессор, надо сделать то что эта плешивая погань похожая на манька не смогла сделать - пок-пок линтер ниможит без говна;{ мы тупенькие тут все, ссорян(((;;;;{{
я решил зайти издалека, начать с морды и применить реюзабилити, т.е мой текущий проект это подводка к другому ( хайлоуд браузер (пиздорылые никчемные додики из гхугла не могут запилить браузер который бы держал тысячу табов на моей 32 ядерной воркстанции без лагов) а я знаю как это сделать изили)
ну а после него у меня останется куча стафа который ляжет в основу морды для игрового движка, ага.
>я никуда не вступал, мне похуй на уебищное ооп
Нет, вступил. Взял в руки уеч = будешь жрать ооп-кал на плюсах.
>твою портянку не читал, если ты не можешь лаконично излагать мысли - твой интеллект низок.
Так ты сам партянками пишешь, лол.
>про свой движок у меня даже целый тред в гд есть, и сделать его нихуя не сложно, все уже давно изобретено
Если бы так было, никто бы не делал что-то новое.
>и самый умный вариант это пиздить у топов (т.е эпиков)
Ебать ты калоед.
> Взял в руки уеч = будешь жрать ооп-кал на плюсах
ну пока что хватает лапши. есть один персонаж он клон майнкрафта на лапше захуярил, не вступит в кресты вообще ни разу!
пробрасывание даты между ивентами правда пиздецки отъебало голову, как и всякие крестодаунские заебы типа -24 %% 24, но это ничего страшного..
> партянками пишешь
я не описываю идею, а бугурчу
> Если бы так было, никто бы не делал что-то новое.
а никто и не делает, с 70ых кроме пары маняфантазий нихуя и не поменялось, где были там и есть, ну да чутка реще стало, по сути все тоже самое
а как уперлись в мура, так и начались манявры, - а давайте физончик на нейросетях посчитаем плиииз :?
инцелы из интела даже попытались нейроночку засунуть в свой кипятильник для радиатора, но вышла как обычно даунская хуита ( но от чсвешных додиков никто иного и не ожидал )
в общем все движется в сторону нейро-оптимизации и шорткатов, ебать в лоб больше не получится физически
поэтому либо будет матрица, либо все пойдут нахуй в каменный век и стагнацию в лучшем случае
> Ебать ты калоед.
попизди мне.. эпики в соло пушат весь геймдев и заодно фильм_дев, если б не они ты как и все остальные жрали говно
и в пятой части (уеп) уже такая йоба как вирчуал меш, вкупе с дин светом - это гейм ченжер
Челище.. Либо ты нормально будешь делать всё - либо будет дрисня.
Алсо, твой "движок" должен быть на 100 строк кода или вроде того. Вместе с рендером. Хз чего ты там в лапшичные ооп-помои перекатился с своего движка. Не смог в шейдеры и постпроцессинг?
> Челище.. Либо ты будешь делать - либо нет
мне твой максимализм с перфекционизмом очень сильно не близок, понимаешь?
> своего движка
у меня нет, а только в планах, ты вообще следишь за нитью?
> движок" должен быть на 100 строк кода или вроде того
ну вот я тоже хуй знает откуда у этих даунов 30 гигов говнища (и почти сотка гигов при компайле), когда годот вешает три сотки мб
>мне твой максимализм с перфекционизмом очень сильно не близок, понимаешь?
Да, понимаю. Некотоыре люди просто любят жрать дерьмо. Ты привык и продолжаешь это делать, оправдываясь на хуйне.
>у меня нет, а только в планах, ты вообще следишь за нитью?
Так тред был месяца джва назад. Ты чего, до сих пор двиг не высрал? Ебать ты.
>ну вот я тоже хуй знает откуда у этих даунов 30 гигов говнища (и почти сотка гигов при компайле), когда годот вешает три сотки мб
ООП-дрисня просто. Когда в коде вместо лайтовых эвентов ООП-кал, лапша и прочая хуйня - движок действительно будет весить миллиарды байт.
Говдот тоже дрисня ебаная с ооп-калом, кста, я хз нахуя это говно существует в 2к22. Например моё говнище весит 300~ строк кода и два мегабайта библиотек работы со звуком и i/o. и это я ещё не переписал под ecs некоторые части, только архетипы сделал
Алсо, кажется я не прав в том, что модель акторов/агентов - слишком большая и объемная. Нужно меньше концепций, зачем нужна дополнительная косвенность, если она не нужна? Нужна ещё более простая реализация threadsafety-эвентов. Если конечно конечно получится такое найти и сделать, агенты-то гораздо проще в реализации и в понимании, как и весь ерланг.
> понимаю
тогда зачем тралишь тупостью?
> Так тред был месяца джва назад
07/02/22 а кажется будто полгода минимум
> до сих пор
сука долбоеб ты даже предыдущий мой пост не прочитал..
> нахуя
к упити ровно такой же вопрос, как и ко всякому унижену и прочему калу
> весит 300~ строк кода и два мегабайта библиотек
если там нет графона и инструментов разработки то даже не заикайся
У тебя нихуя не получится, потому что акторы не делят стейт, а в JS есть дохуище способов разделить стейт. И к тому же, это нахуй не нужно впринципе, потому что компоненты условного реакта умеют обновляться асинхронно.
Просто так реализовывать акторы на JS нахуй не нужно, потому что Erlang это и есть акторы, только ахуенно эффективные и крутые и написанные на C. Так что умерь свой NIH и запили что-нибудь реально полезное или интересное
>>2368232
cython это не язык, я хуйня для прослойки питона в C. Нигде больше это не используется
>>2368265
Анон, мы говорим о других акторах. Мы говорим об акторах из акторов для многопоточных систем. Ты говоришь об акторах их геймдева. Это разные вещи.
---
Какой нахуй геймдев, вы в шапку треда посмотрите
> Ты говоришь
чтобы аноны не занимались хуйней, а запили препроцесор для сраных крестов без говна и визуального шума
это будет хоть и трата времени, но общественно полезная
и я в душе не ибу о каких вы акторах ведете речь я вообще не читал а сразу отвечал
>У тебя нихуя не получится, потому что акторы не делят стейт, а в JS есть дохуище способов разделить стейт.
Достаточно просто не делить стейт, а если кто-то начнёт делить - поделить его жопу.
> И к тому же, это нахуй не нужно впринципе, потому что компоненты условного реакта умеют обновляться асинхронно.
Реакт нинужон. К тому же эта хуйня не только на жс будет работать, на ерланге (возможно) и с++ будет. По сути это аритектура и для сервера и для клиента, очень кросиво выходит, прямо хорошо, но нужна обвязочка тоже асинхронная и мультипоточная.
> Просто так реализовывать акторы на JS нахуй не нужно, потому что Erlang это и есть акторы, только ахуенно эффективные и крутые и написанные на C. Так что умерь свой NIH и запили что-нибудь реально полезное или интересное
Не одни акторы будут, в этом прикол-то. Каждый раз возвращаюсь к ерлангу и каждый раз возникает NIH, в основном по причинам производительности. Может попробую ECS на ерланге ебануть, но хз, очень хз. Вот теперь возникла идея перепилить вместо акторов простейшие эвенты и отказаться от ерланга навсегда ну или по крайней мере на большей части серверов, хуй конечно в бизнес-логике и платёжках откажешься
>акторы, только ахуенно эффективные и крутые и написанные на C
А нужно чтобы они скомпенлированные были. С статической типизацией, скомпенлированные, эффективные, с встроенными архитектурными паттернами ништяками для них. Ну не работает оно достаточно быстро. Не может оно онлайн без смс 10кк хуйни обработать на одном сервере. А моё поделие на си может, допиленное недавно.
>>2368340
>cython это не язык, я хуйня для прослойки питона в C. Нигде больше это не используется
Ну это как готовый препроцессор на си для дэбилов. И с ништяками. Можно тесты на питоне тут же писать.
Я нихуя не понял, ты хочешь акторы на JavaScript или на C. План что ты сначала пишешь на JS, а потом на С это какая-то хуйня, потому что в первом рантайме оно не нужно, а во втором рантайме оно уже есть в нескольких видах.
Если хочешь посмотреть на конпелируемые акторы, то есть Ergo и Ponylang. А если ты выбираешь эрланг и упираешься в CPU, то ты обосрался, потому что эрланг это для IO bound задачек. На языках с ручным управлением памятью ты в многопоточности будешь сосать хуй, так исторически сложилось.
>Я нихуя не понял, ты хочешь акторы на JavaScript или на C.
Они уже есть, на жс и на с++. Теперь переписываю под сигналы/евенты/легие акторы (ну я ебанулся немног, да).
>План что ты сначала пишешь на JS, а потом на С это какая-то хуйня, потому что в первом рантайме оно не нужно, а во втором рантайме оно уже есть в нескольких видах.
Суть в том чтобы иметь одинаковую архитектуру на клиенте и на сервере. Чтобы данные вообще не пришлось как-то преобразовыват. Просто отправил бинари, обработал, получил, обработал, отправил, получил~ Одинаковая обработка, одна и та же последовательность байтов в пакетах, сплошные профиты короче.
На JS акторы/евенты/сигналы нужны именно для того чобы была одинаковая архитектура, тут буксанул на месяц уже, нихуя не понятна, все остальные хуйни по мануалом вкурил за пару дней.
> Если хочешь посмотреть на конпелируемые акторы, то есть Ergo и Ponylang.
Первый на го, вроде норм, но платно. Нахуй нужно лол. Второй ооп, хз конечно, нужно посмотреть.
> А если ты выбираешь эрланг и упираешься в CPU, то ты обосрался, потому что эрланг это для IO bound задачек.
Так мне нужон и io и очень быстрый код. В этом проблема.
> На языках с ручным управлением памятью ты в многопоточности будешь сосать хуй, так исторически сложилось.
Вот тут вот я нашел вариант когда с многопоточностью не сосу хуй. Енто ecs и data-oriented. Всё в принципе хорошо работает. Но осталось совладать с акторами или их заменой. Очень туго идёт. Очень.
Если им дать пустой список, то get() возвращает nil, а fetch!() :error, зачем нужна эта разница?
Функции с bang (восклицательным знаком в названии) выбрасывают исключения в случае ошибки, что ведет за собой падение вызывающего процесса. Удобно при запуске приложений читать конфиги через fetch! - если какого-то важного конфига нет, то приложение не стартанет и ты об этом точно узнаешь
Ну вот когда ты знаешь что ключ обязательно нужен и без него нельзя дальше работать, то делай fetch!()
Если он не обязательно нужен, или есть дефолтное значение, то get()
>>2368676
> Суть в том чтобы иметь одинаковую архитектуру на клиенте и на сервере
Это никому нахуй не нужно. Программы решают проблемы, а не занимаются унификацией архитектуры. Меняй риторику: если одинаковая архитектура где-то нужна, то она должна решать какую-то проблему. Вот об этом проблеме и расскажи ,но я уверен что ты нихуя не расскажешь, потому что изначально какой-то велосипед хуяришь
Я так и не понял, ты хочешь один язык на бэке и фронте? Если так, то вылезай из манямирка, такие технологии живут только на презентациях. Посмотри на cljs и scalajs и тех кто этим пользуется. Подумай ещё раз.
> Первый на го, вроде норм, но платно
Нет, не платно.
> Так мне нужон и io и очень быстрый код. В этом проблема.
Не, тебе в первую очередь нужно повзрослеть. У тебя не получится усидеть на двух стульях ни в каком рантайме. За всю историю программирования не было ни одной такой системы не потому что их разрабы тупые, а потому что это банально невозможно.
Посмотри на C++ и то, как там попытались запилить сразу все фичи. В итоге, люди получили ахуенно жирный язык, где фичи из разных сфер приводят к довольно стрёмным багам (например подебажь std::shared_ptr и boost::asio). В итоге, в C++ это вылилось в то, что на языке выбирают какой-то сабсет фичей и работают с ним, что не особо похоже на "CPU и IO эффективный язык"
Кароче, на двух стульях не усидеть, просто повзрослей.
> Енто ecs и data-oriented
> осталось совладать с акторами или их заменой
Ты какую проблему изначально решаешь, дорогой? Ты просто вкатился в тред по Elixir, начал пиздеть про Javascript, а потом просто начал срать баззвордами и уверять меня и всех окружающих в том, что ты сможешь решить все-все-все проблемы разработки какой-то своей хуйнёй.
Кароче, давай начнём с простого: какую проблему ты изначально решаешь и где ссылочка на репу с этим проектом?
>Меняй риторику: если одинаковая архитектура где-то нужна, то она должна решать какую-то проблему. Вот об этом проблеме и расскажи ,но я уверен что ты нихуя не расскажешь, потому что изначально какой-то велосипед хуяришь
Всё просто - приложение должно оффлайн работать, при отключении сети. И оно должно на говянном оборудовании работать. И оно должно работать на говянном оборудовании очень быстро.
>Я так и не понял, ты хочешь один язык на бэке и фронте? Если так, то вылезай из манямирка, такие технологии живут только на презентациях.
Одинаковую архитектуру. На бэке у меня эликсир уже заведён для банковской хуйни и частей бизнес-логики, там всё в порядке, это отдельные апи.
Но для всего остального, ради уменьшение трансформации данных, нужна полностью одинаковая архитектура.
> Посмотри на cljs и scalajs и тех кто этим пользуется. Подумай ещё раз.
Этож параша оопешная, не понимаю ничего из этой хуиты.
> Нет, не платно.
Хз, там какие-то тарифные планы, закрыл сразу как увидел.
> а потому что это банально невозможно.
Ты что-то явно не то представил себе.
> Ты какую проблему изначально решаешь, дорогой? Ты просто вкатился в тред по Elixir, начал пиздеть про Javascript, а потом просто начал срать баззвордами и уверять меня и всех окружающих в том, что ты сможешь решить все-все-все проблемы разработки какой-то своей хуйнёй.
> Кароче, давай начнём с простого: какую проблему ты изначально решаешь
Смотри значит, проблема токова. Нужно одинаковое преобразование данных на клиенте и на сервере. Минимальная модификация данных, для уменьшение сетевых издержек. Максимальная производительность для сервера и клиента. Простые взаимодействия между кластерами. Простые взаимодействия между клиентами (способность нормально работать в локальных сетях). Синхронизация клиента и сервера в произвольные промежутки времени.
Проблем-то особо и нет на самом деле, сейчас протестировал джва варианта эвентов на кластере, пока что работает, но блокировки есть. С БД пока никак не взаимодействовал.
>и где ссылочка на репу с этим проектом?
Вероятнее всего нигде не будет, если лицензия не изменится, ибо нда уже работает
> Нужно одинаковое преобразование данных на клиенте и на сервере
Это не проблема, это ты себе какую-то хуйню придумал. Проблема звучит так "у моего веб приложения высокий латенси". То что ты придумал, оторвано от реальности и вообще нихуя не похоже не правду. Ты сам какого-то хуя решил что у веб приложений узкое место это энкодинг и декодинг данных. Ну поздравляю тебя, во-первых, это нихуя не узкое место и кушает очень мало вычислительной мощности, а во-вторых, есть дохуище форматов для быстрого кодирования, а в-третьих, в браузере может крутиться только Javascript и WASM. В случае с JS, если ты напишешь Elixir на JS, ты получишь просто ещё более жирный рантайм и об оптимизациях энкодинга просто забудь. В случае с WASM, ты получишь эликсир в браузере, который кастрирован и нихуя не работает с UI, да и работает вообще на полутора платформах
Кароче, мой вердикт в том, что ты просто шиз какой-то и несёшь хуйню от реальности оторванную. Могу тебе посоветовать почаще выходить из дома и общатсья с живыми людьми, а то ты уже в каком-то вымышленном мире живёшь и пытаешься сделать JavaScript быстрее, написав на нём Elixir
А если честно, мне тебя тупо жаль, дорогой, ты уже безвозвратно потерян в шизе какой-то
Ебать ты нафантазировал, лол. У меня данные под 280 герц могут обновляться, например, ты правда думаешь что в 280 герц любые манипуляции с данными нихуя не занимают время? и это бизнес-логика которую минимум в трёх приложениях не получится кастрировать
В реальности существуют не только вот эти вот твои сайты и прочая веб-хуйня, которую на эликсире ты пишешь, тут всё очень сложно.
Какие блять герц? Ты же только что хотел Elixir написать на Javascript. Ты реально уже какую-то хуйню несёшь просто. У нас тут тред про эликсир, ты ещё ни разу нихуя по топику не написал, а сейчас ещё про какие-то 280 герц вспомнил. Ты реально больной чтоли?
280 герц это 280 раз в секунду, даже убитый микропроцессор из 2000 года может в 10^7 операций в секунду. Ты что там такое делаешь, ебанутый, что у тебя 280 раз в секунду посчитать не удаётся, и какого хуя ты делаешь это на эликсире? И причём тут javascript, долбоёб? И причём тут оффлайн? И причём тут акторы? Ты же бессвязную хуйню просто срёшь, долбоёб
Ладно, открою вебмакаке иной мир, так и быть, не рвись ты только. Смотри какая задача красивая, у тебя никогда такой не будет.
С клиентов приходят данные с частотой 70-350 герц. Может потом больше будет, задача для 800 герц уже будет не моя.
Эти данные нужно симулировать и обрабатывать: на устройстве клиента; на местном локальном сервере; в кластере с интернетов.
Симуляция на оче хуевом клиенте выполняется один такт за 700-900мс, иногда вообще до нескольких секунд, такие клиенты проводят симуляции в отложенным режиме, если нет связи с интернетами. Чем круче клиент - тем больше симуляций на нём. Симуляция на локальном сервере должны выполняются на частоте 70-90 герц минимум. В облаке или каком-нибудь особо мощном интернет-сервере до 300 герц, в кластере должно на максималке работать. Так же можно выставлять точность симуляций, чтобы получать приблизительные результаты даже на тонких клиентах достаточно быстро.
Всё это должно работать максимально быстро, иметь связь между серверами и клиентами, так же локальные сети между клиентами, так же должно минимально проебывать данные, часть данных визуализировать, каждое устройств и каждый кластер иметь acid по результатам симуляций, конечная согласованность для данных, все эти мутные фишки по бд.
А ерлан я воткнул на кластер из трёх серверов, оно обрабатывает прост хуйню вроде оплаты.
Можешь начинать завидовать.
Малаца, а хули ты в этом треде забыл-то?
Во-первых, что такое эта симуляция? Просто абстрактный код/алгоритм или какой-то бинарь, который нужно запустить или что вообще?
Во-вторых, почему у вас "симуляции" исполняются на клиентах? Майнинг на телефонах юзеров пиратских кинотеатров себя не оправдал уже давным давно.
В-третьих, причём тут вообще связность клиентов между друг другом и всё такое?
А самое главное, ты что в этом треде-то забыл, чудовище?
>Малаца, а хули ты в этом треде забыл-то?
Единственный тред в котором многопоточность, многопроцессорность и кластеры работают нормально, очевидно же.
>Просто абстрактный код/алгоритм или какой-то бинарь, который нужно запустить или что вообще?
Алгоритм с математикой, который можно компенлировать и переписывать под любой клиент.
>Во-вторых, почему у вас "симуляции" исполняются на клиентах? Майнинг на телефонах юзеров пиратских кинотеатров себя не оправдал уже давным давно.
Потому что клиентам нужно знать здесь и сейчас результаты. Даже с низкой точностью.
>В-третьих, причём тут вообще связность клиентов между друг другом и всё такое?
Чтобы сделать кластер из клиентов.
>А самое главное, ты что в этом треде-то забыл, чудовище?
Свободное общение, где хочу там и сру, очевидно же. Лучше бы не рвался, а подсказал как сделать как в эликсире, только быстро.
> Чтобы сделать кластер из клиентов.
Связанные машины это по определению кластер. Я спросил, нахуя кластер вообще нужен? Нахуя всем симулировать вместе?
Если что, в твоей задаче эликсир нахуй не нужен. Elixir/Erlang это типа отдельная экосистема, и это нельзя сделать на других платформах.
Например, если тебе нужно что-то считать на клиентах и как-то это координировать, всё будет зависеть от того какая конкретно координация нужна. Типа, что из CAP и насколько вообще нужно уметь считать что-то отдельно. Судя по тому что ты сказал, тут нужен какой-то Gossip с Last Write Wins (если нужно high avability) или алгоритмы типа Cademilia или Chord, чтобы уметь в мэш кластере от любой ноды находить любую ноду. Для этого акторы не нужны
И если у тебя вычисления занимают 700-900мс, то энкодинг данных в JSON/Msgpack или даже protobuf будет занимать нихуя. Даже на самых слабых клиентах браузер декодирует JSON с помощью SimdJson или типа того, поэтому это будет тупо экономия на спичках. Лучше подумай как сделать эту "симуляцию" быстрее и как сделать поиск пути в кластере более эффективным
Потому что одна машина не может симулировать, очевидно же. Если нужны срочные оффлайн вычисления - машины в локальной сети должны просто взять и вычислить с максимально возможной мощностью часть данных.
>>2369068
> Если что, в твоей задаче эликсир нахуй не нужен. Elixir/Erlang это типа отдельная экосистема, и это нельзя сделать на других платформах.
Прототипы на эликсире работают и на плюсах.
> Gossip с Last Write Wins (если нужно high avability)
Сейчас согласованность пока что особо не нужна. Сейчас все вычисления работают на ecs, вернее через сверхнаивную реализацию ecs, и распределяются тоже среди таких же систем на других машинах. Каждый клиент в кластере решает либо часть массива данных, либо один из массивов данных, в зависимости от мощности. Итоги симуляции отправляются к клиенту который инициировал симуляцию, именно на этом моменте будет различные CRDT, сейчас просто конечная согласованность. Хз как работать это должно на самом деле, подумаю ещё.
Но спасибо, записал варианты.
> или алгоритмы типа Cademilia или Chord
Камелию использую, чрод, ну это просто выбор ноды, это уже на уровне сети, похуй, но тоже записал, нужно подумат над этим.
>Для этого акторы не нужны
Нуу, эээ, наверное?
Акторы, как и ерланг в целом, решают проблему во-первых тредов, во-вторых просто проблему общения между любыми частями кода на любом клиенте. По сути это самая большая проблема от которой жопа болит. Даже согласованность кажется легкой задачей хуле я её не писал ещё
>>2369071
Не-не, это когда тухлые клиенты сами пытаются в вычилсения.
Обычно они просто должны слать на интернет-кластер/локальные-машины. И в такой ситуации данные стрим-потоком в дохуя герц идут.
>С клиентов приходят данные с частотой 70-350 герц
Смеюсь. Про термин RPS слышал когд-нибудь? Очень шизово слышать ГЕРЦ в таком контексте
Ты просто ньюфажина, тикрейт, например, тоже измеряете в герцах.
>>2369128
Это https://en.wikipedia.org/wiki/Entity_component_system
Изначально всё это говно было игрой, надеюсь позже тоже будет игрой, когда нда спадёт осенью выкачу в паблик атвичаю
Когда своими маняфантазиями делился с челиком он сказал что есть заказ как раз именно под эту архитектуру, прямо один в один.
Понял, тот самый гейдевелопмент в кластере и на JavaScript на клиентах, где один шаг вычисляется за 700мс. Я так и думал, это же очевидно
Не ну раньше там просто было ecs на сервере и на клиенте, ничего серьезного, эликсир и плюсы были просто как отдельные гей-сервера. А потом оказалось что это может сработать и для некоторых показателей в лабахназаводах. Гей-девелопент полезен, я же говорил, говорил!
В целом ничего не изменилось, просто немного дополнительных условий, ящитаю хуйня, выебут не сильно если ошибусь 8 лет тюрьмы наверн по минималке
>почитать свежую инфу про настройку приложений
Чем тебе не хватает официальной документации? https://hexdocs.pm/elixir/1.12/Config.html
>Посмотри на cljs и scalajs и тех кто этим пользуется
>>2368814
>Этож параша оопешная, не понимаю ничего из этой хуиты.
Так, вот щас обидно было.
мимо кложурист-функциональщик
Хосе что-там пизданул про dependecy injection через глобальный конфиг, как же я проиграл, вы че ебанутые?
Сейчас бы мокать глобальный контекст и проебывать асинхронность тестов.
Чево? Глобальный контекст? Что ты несёшь?
Показываю на пальцах, запоминай.
1. Мокать нужно взаимодействия с внешними системами. Если ты мокаешь что-то внутреннее, то ты занимаешься хуйнёй.
2. Взаимодействия практически всегда stateful. Поэтому, ты имеешь какие-то процессы, которые со стейтом работают.
3. Ты создаёшь defprotocol и две имплементации к нему: тестовую и продовую. Например, если ты пишешь клиент к двочу, то в продовой у тебя структура типа %Dvach.HTTP{url: url, conn: conn, cookie: cookie}, а тестовая декларируется во время теста и выглядит просто как %Dvach.Test{}. Тестовую структуру можно делать ручками либо через Promox.
Сам протокол работает с этими структурами и выполняет какие-то действия с ними. Банальный протокол для двача будет иметь функции connect(), get_thread(), post_in_thread()
4. Генсервер из пункта 2 при инициализации получает аргументом (или как-то ещё) структуру, и работает с ней через протокол
Конец
Чево? Глобальный контекст? Что ты несёшь?
Показываю на пальцах, запоминай.
1. Мокать нужно взаимодействия с внешними системами. Если ты мокаешь что-то внутреннее, то ты занимаешься хуйнёй.
2. Взаимодействия практически всегда stateful. Поэтому, ты имеешь какие-то процессы, которые со стейтом работают.
3. Ты создаёшь defprotocol и две имплементации к нему: тестовую и продовую. Например, если ты пишешь клиент к двочу, то в продовой у тебя структура типа %Dvach.HTTP{url: url, conn: conn, cookie: cookie}, а тестовая декларируется во время теста и выглядит просто как %Dvach.Test{}. Тестовую структуру можно делать ручками либо через Promox.
Сам протокол работает с этими структурами и выполняет какие-то действия с ними. Банальный протокол для двача будет иметь функции connect(), get_thread(), post_in_thread()
4. Генсервер из пункта 2 при инициализации получает аргументом (или как-то ещё) структуру, и работает с ней через протокол
Конец
Ты не понял, проблема не в том как абстрагировать зависимость, а том как бы ее удобнее "передать" в модуль. И не всегда это можно сделать через стейт генсервера, может быть у тебя модуль в котором функция должна хитровыебанно получить данные из апи, никакого стейта только бизнес-логика, однако для теста нужно мокать обращение по http.
Да при чем тут глобальный конфиг, ноль информации в твоих каментах.
Такое ощущение что ты перед кем-то выйобуешься.
Передо мной не нужно, для меня ты никто.
мимо-хосе
Ну так дёрнуть что-то по API это типа функция
get_data(url, cookie, ...)
Гду url, cookie и вся хуйня берутся из конфига или другого хранилища для стейта (Я же надеюсь ты это не хардкодишь). Ты эту хуйню в итоге преврати в
defprotocol DataGetter do
def get(getter)
end
И сделай
defmodule HTTPGetter do
defstruct ~w[url cookie govno]a
end
А для тестов сделай
defmodule TestGetter do
defstruct []
defimpl DataGetter do
def get(_), do: :this_is_data
end
end
И вот у тебя красиво всё получилось
Так же как ты бы передавал URL в пулл: через application env, просто через аргументы при запуске, при чтении конфигурации откуда-то там и т.д.
Какие распределнные системы, маня? У него же, как и у Erlang все очень хуево с прозводительностью на цпу задачах. Т.е. там норм только паралельный и маиссвный IO. Любые числодробильные операции, манипуляция со структурами данных - это полный пиздец. Собственно BEAM'ские языки это одни из самых медленных скриптух. Оно в телекоме живет только засчет того, что там довольно тупые программы по пересылке паектов сетевых. Как запахнет более комплексными задачами - пиши пропало.
Собственно просто глянись вокруг, всё на JVM или на Go в распределнном мире. От куберов и номадов до всяких Apache Flink, Spark и Kafka.
> Какие распределнные системы, маня? У него же, как и у Erlang все очень хуево с прозводительностью на цпу задачах. Т.е. там норм только паралельный и маиссвный IO
В каком месте распределённые системы это CPU bound? Ты когда последний раз спал, дорогой?
> Собственно BEAM'ские языки это одни из самых медленных скриптух
Собственно BEAM-овские языки в среднем работают быстрее и эффективнее по памяти многих других динтипизированных языков. Особенно начиная с OTP24
> Собственно просто глянись вокруг, всё на JVM или на Go в распределнном мире. От куберов и номадов до всяких Apache Flink, Spark и Kafka.
Собственно просто глянись вокруг, от phoenix, couchdb, riak до всяких emqx, membrane и rabbitmq
> В каком месте распределённые системы это CPU bound? Ты когда последний раз спал, дорогой?
Они всегда ими были. Любая БД способная к кластеризации это распределенная система. Там хуева туча CPU bound: индексы, поиск, парсинг запросов итд. Не говоря уже об огромном количестве задач где во главе угла стоит распределенный процессинг: flink, spark, hazelcast jet итд.
>Собственно BEAM-овские языки в среднем работают быстрее и эффективнее по памяти многих других динтипизированных языков. Особенно начиная с OTP24
Только по памяти и только иногда. По CPU там такая пропасть, что делает их неюзабельными при малейшем намеке на CPU bound. Т.е. ими можно только IO кромсать и не более того.
>Собственно просто глянись вокруг, от phoenix, couchdb, riak до всяких emqx, membrane и rabbitmq
Собственно и всё. Couchdb и riak простейшая kv-хуйня, на фоне cassandra, prometheus, elastic и десятков других решений. Rabbitmq и emqx как раз случай про IO в вакуме, там почти нет CPU bound. Если бы это был более сложный мессенджинг типа Apache Pulsar, то BEAM бы не подошел.
Erlang/Elixir разработчик с 6 годами стажа итт.
Очевидно, что в этих ваших CPU bound задачах OTP сосет за обе щеки по сравнению с той же Java, но никто и не позиционировал никогда erlang как универсальный ЯП, напротив, это изначально супер узкоспециализированная хуйня для перекладывания сообщений, с чем она охуеть как хорошо справляется. Хуй где еще есть такая простая работа с concurrency из коробки (напишешь пару простых GenServer'ов и будешь плеваться кровью, если тебе придется в том же Ruby что-то похожее организовать, будешь ебаться с сайдкиком и редисом), не говоря уже о том, что можно одним конфигом на ~10 строк кластер захуярить.
Ну и веб пердолить на всем этом очень хорошо, phoenix channels и live view это пиздец как круто, уверен, что подобное можно и на других технологиях сделать, но это будет геммор.
Ну и смотря какой CPU bound конечно. С тем же Flow можно охуенно просто распараллелить вычисления так, чтобы все ядра были задействованны. Это делается буквально так же как обычная работа со списками, только в другой обертке.
Flow, конечно, удобная штука и довольно элегантная штука, но
1. Всё равно не подходит для CPU bound, потому что у BEAM языков довольно жирный рантайм. И тут ускорение на N ядер не поможет, потому что у тебя любые операции тупо в 10-100 раз медленнее чем в компилируемых в натив языках.
2. Ирл практически бесполезная, потому что практически никогда такой тупенький пайплайн никого не устраивает. Я предпочитваю всё делать ручками через GenStage, ну или хотя бы Broadway. Тот же Flow я только в каких-то скриптах типа "залей большой CSV в базу", которые вызываются ручками раз в неделю, использовал.
мимо ОП
>Хуй где еще есть такая простая работа с concurrency из коробки
Го же, охуенно простая работа с конкаренси, проще некуда какбе.
Зачем брать Erlang/Elixir и ковыряться в несвежих библиотеках, которые пишутся рандомами на гитхабе, если моя задача, это обработать HTTP запрос и положить данные в какую-нибудь Kafka или Clickhouse?
Ну для твоих примтивных задач, смысла никаокго нет. Обмазывайся каким-нибудь пистоном убогим. Эликсир это не для мещан типа тебя.
Куда ты там сообщения передавать собрался, имбецил? Ты понимаешь, что нужно вэлью нести, а не монадки по углам дрочить? Сказано же тебе, что нужно обработать запрос и записать в очередь или базу. У тебя тут исключительно IO-bound задача.
Макака, тихо. Тебе долбоебу только лопатой джейсоны перекидывать можно. Message-passing это вообще один из основных подходам в распределенных системах. Применений масса различные IoT, построение event mesh архитектур, маршрутизация данных в развесистых observability пайплайнах итд. лучше съеби не позорься.
https://github.com/kvakvs
Это ты? На завод устроился?)
> моя задача, это обработать HTTP запрос и положить данные в какую-нибудь Kafka или Clickhouse
Ты хуйню в вакууме придумал, дорогой. Задача на самом деле звучит скорее всего как-то типа "сделать бэк, который обновляется без остановки, и который скейлится в зависимости от хуйни", просто тебе как низшей макаке прилетела лишь маленькая часть этой большой задачи, в виде "написать тупейший апи".
И вот проблема непонимания эликсира как языка где-то тут и лежит: дефолтная макака не понимает, что в эликсире мыслят на порядок шире.
Когда каждый гоферный микросервис реализуется в виде одного-двух модулей, и когда межсервисное взаимодействие никак не отличается от межтредового, задачи типа "высри апи для хуйни" либо не стоят вообще, либо делаются за час.
И это не пиздёж двачера. Тот же whatsapp и написали всего лишь 9 человек. А запилить распределённый скрапер уровня гугловских роботов, который умеет в пайплайнинг, распределение проксей и всю хуйню можно меньше чем за 5 дней одному, параллельно почитвая доку
>в эликсире мыслят на порядок шире
Ну да, например как найти работу и как объяснить престарелым родителям, что ты возвращаешься в свою комнату и тебе нужен борщ
Elixir делает Erlang полностью ненужным? Или таки есть нюансы и кое-где лучше все еще использовать эрланг?
Удваиваю вопрос. И вообще нужно ли учить Erlang перед вкатыванием в Elixir?
Не вижу ни одной причины начинать писать новый проект на Erlang, а не на Elixir. Разве что у вас есть команда из овер 9000 эрлангистов, которые на Elixir не писали никогда, но и то они за два дня разберутся.
>>2397668
>И вообще нужно ли учить Erlang перед вкатыванием в Elixir?
Нужно понять принципы из OTP, но понять их можно и через изучение Elixir. Вообще, выучив один из этих языков, ты автоматически знаешь уже и второй, останется только денек на синтаксис потратить.
Спасибо. Смотрю сейчас на эликсир, выглядит очень няшно. Ешя ряд вопросов, если не против:
1. Можешь еще подсказать по распределнным структурам данных? Что в ходу в BEAM экосистеме? Например, распределнная между несколькими нодами мапа или сет. Сам я подобные вещи на JVM раньше делал, у нас это решается либами, либо всякими монструозными IMDG типа Ignite и Hazelcast, которые можно встравать сразу в приложение, и оно будет само кластеризоваться, выполнять всю херню в фоне типа выбора матеров, дискавери итд.
2. Например, как писали аноны выше, я столкнулся с проблемой недостаточного перфоманса на какой-то числодробильней хуйне. Можно ли делать как-то, так называемые, нативные модули? По аналогии с сишными в пистонах и рубях.
>Можно ли делать как-то, так называемые, нативные модули? По аналогии с сишными в пистонах и рубях.
https://www.erlang.org/doc/tutorial/nif.html
Возможно ты прав, но тогда я не понимаю как язык с самыми высокими зп может быть для борщехлёбов
>>2397653
Да, после Elixir знать Erlang нахуй не нужно. Ну, может для общего развития и поддержки легаси узнать его, конечно, стоит, но сейчас сам язык это просто тонны духоты, которую давно решили в Elixir. Возможно сейчас набегут деды защищать свой любимый Erlang, но это не больше чем просто фанатизм. Elixir это тупо better Erlang. Примерно как Kotlin и Java
>>2397745
1. Структур дохуя, но у них разные CAP-семантики, перформансы и т.д. А так, на эликсире есть всё: от простейших CRDT или CA key-value до распределённых AP/CA баз данных с автоматическим рекавери. Смотри на свой юзкейс.
Все дискавери и общения между нодами в Elixir стандартизированы через Erlang Distribution. А сервис-дискавери можно делать через няшный libcluster
2. Да, можно делать нативные модули. Выборов как это сделать дохуя. Самый удобный -- nif на расте. На расте, потому что либа для нифов очень удобная, да и у BEAM высокие требования к нативным модулям: никаких ошибок, прерывания спустя 1мс работы и т.д.
Если не хочется ебаться с нифами, всегда можно написать порт (aka Port). Это тупо отдельный системный тред, с которым ты общаешься через stdio
>Примерно как Kotlin и Java
Воу, палехче. Коклен - это хайповая довольно неконсистетная хуйня и просто куча сахара. Которая взлетела по большей части только на мобилках из-за того, что у них даже нормальной жвм нет и какие-то каловые массы вместо человеческих рантаймов.
Чисто по Elixir
https://github.com/dashbitco/broadway
https://github.com/dashbitco/flow
https://github.com/nerves-project/nerves
Чуть попроще
https://github.com/sorentwo/oban
А так вот это очень крутая штука https://github.com/lasp-lang/partisan как и сам lasp. В репозитории много интересных вещей из области распределенных систем.
>>2408701
еще вспомнил:
https://vaxine.io/ который на базе так же интересного https://www.antidotedb.eu/
О, наконец-то нормальный аналог AP mnesia на эликсире, спасибо, анон
Не нужен когда есть Phoenix. А для простых HTTP API и обычный Plug сойдет.
>Не нужен когда есть Phoenix.
Как будто феникс круче. Обычное мвц-говно размером 100500+ строк кода.
Круче, не круче. Но для веба, читай "мвц-говна" отлично подходит и удобный, хоть и относительно (других проектов на эликсире, а не какого-нибудь монстра вроде RoR/Django) тяжелый. Хотя сам я стараюсь его не тащить и обходиться просто плагом, когда нужно обычную API сделать.
на сайте эликсира ссылки на слак/irc/дискорд. Все живые, особенно в слаке
Не могу установить пакеты esl-erlang и elixir с репозитория https://packages.erlang-solutions.com, получаю Failed to fetch http://binaries.erlang-solutions.com/ubuntu/dists/focal/InRelease Connection failed хотя в браузере репозиторий открывается. У кого-то еще была такая проблема?
На годноте сами работаем, ты уж извини.
Но вообще периодически появляются.
Для bottom-up проектирования, не всё же вотерфоллы дрочить со статикодриснёй.
Так тогда питон лучше. Особенно когда речь идет о поиске персонала.
>у эликсира динамическая типизация, как в петухоне
что ты блядь несёшь
динамическая типизация, т.е. со сменой типов у переменных, может быть только там где есть переменные. в эликсире переменных нет, значит и динамической типизации нет
Ну предположим нам нужно описать функцию, которая принимает в себя некую структуру, и возвращает некое число. Как это сделать? Или эликсир будет в рантайме проверять что мы передали структуру, а не строку или булеан? Если это так, то как на нём пишут высоконагруженные системы, когда всё может упасть из-за того что в функцию передали не тот тип?
Тут подход как в ноде, ебошишь еще больше инстансов, просто в отличии от ноды, инфраструктура для параллельных систем встроена в язык.
мимо
>Если это так, то как на нём пишут
В эликсире тип описывается через кортеж
например
{:leaf, 1} - конечный элемент
или
{:tree, [{:leaf, 3}, {:leaf, 4}]} - структура
ты пишешь функцию:
def sum({:leaf, value}), do: value
def sum({:tree, list}), do: sum(list)
def sum([head]), do: sum(head)
def sum([head, tail]), do: sum(head) + sum(tail)
def sum([]), do: 0
потом херачишь
data = {:tree, [{:leaf, 3}, {:leaf, 4}]}
sum(data)
7
Работа со структурами происходит через паттерн-матчинг. В смысле тебе не придётся делать if is_array(data) и прочее говно. Там всё в тыщу раз красивее
>Работа со структурами происходит через паттерн-матчинг.
Это буквально то, что он описывал
>Или эликсир будет в рантайме проверять что мы передали структуру, а не строку или булеан?
для паттерн-матчинга применяется какая-то оптимизация. он быстрый, на этот счёт можно не ебать себе голову
Суть не в быстроте, а то что в функцию может прилететь что-то, что не было описано паттерном, и тогда всё приложение наебнётся. В статически-типизированных языках такая ошибка отлетела бы на этапе компиляции.
>что не было описано паттерном, и тогда всё приложение наебнётся
Тут надо понимать, что эрланг/эликсир юзают модель акторов и собственную ВМ, которые по сути являются микросервисами с оркестратором и обладают специфической философией которая вполне подходит для систем мягкого реального времени. Падать нормально, если ты сможешь встать.
>В Erlang есть концепция — let it crash. Смысл ее заключается в том, что программист не должен писать код пытаясь избежать все возможные проблемные кейсы — поскольку невозможно предусмотреть все. Erlang — позволяет упасть — но так чтобы падение было контролируемым — что делать после падения — перевести единицу кода к стабильному состоянию. Это достигается с помощью модели акторов.
код падает, идёшь и чинишь, перезапускаешь
для упрощения жизни есть спеки у функций и статический анализатор dialyzer
многие поначалу хотеть строгой типизации для эликсира, но в итоге приходить к мнению что она не сочетается с базовой концепцией эрланга. у нестрогой типизации есть свои плюсы - лёгкость прототипирования. на самом деле то что ты пишешь - вовсе не проблема в реальных проектах
> у нестрогой типизации есть свои плюсы - лёгкость прототипирования. на самом деле то что ты пишешь - вовсе не проблема в реальных проектах
А как рефакторить то что ты напрототипизировал? Я всю жизнь программировал на языках со строгой типизацией, я просто не понимаю как можно жить без типов.
>динамическая типизация, т.е. со сменой типов у переменных, может быть только там где есть переменные
В Clojure, получается, тоже динамической типизации нет? Переменных-то нема, только let-биндинги.
>Я всю жизнь программировал на языках со строгой типизацией, я просто не понимаю как можно жить без типов.
>без типов
Очередной дурачок, путающий оси типизации статическая/динамическая и сильная/слабая.
Дурачок, давай перефразирую для тебя. Я не понимаю как жить без проверки типов компилятором, а надеяться на рантайм
>c10k
Так это про переиспользование дескрипторов, в том же пистоне давно решается, да и скорее всего на вебморде nginx будет, зачем голому приложению в сетку смотреть?
>Переменных-то нема, только let-биндинги.
Почти как и в эликсире. В эликсире и кложе иммутабельность из коробки. А actor-model - в эликсире из коробки, а в кложе прикручивается отдельно.
Блин, котаны, вопрос про динамическую/статическую типизацию - на самом деле про динамическую диспетчеризацию. Это один из китов ООП (правильного, того, что actor-model).
Напомню китов:
- инкапсуляция (актор хранит свой стейт, и никакой другой актор не может на этот стейт повлиять напрямую)
- динамическая диспетчеризация (актор может отправить любому другому актору любое сообщение. переводя на привычный язык - в рантайме можно вызывать функцию/метод, не существовавшую на момент компиляции)
- позднее связывание (что делает с сообщением решает получатель - когда отвечать, что отвечать, отвечать ли вообще).
“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.”
~ Alan Kay
https://medium.com/javascript-scene/the-forgotten-history-of-oop-88d71b9b2d9f
Так вот. Вы выбираете одно из двух - либо настоящий messaging, либо строгую типизацию известную на этапе compile-time. В эрланге первое.
>Вы выбираете одно из двух - либо настоящий messaging, либо строгую типизацию известную на этапе compile-time.
Либо выбираешь Common Lisp с его CLOS, с одной стороны, и декларациями типов, с другой, и сидишь одной жопой сразу на двух стульях.
>когда всё может упасть из-за того что в функцию передали не тот тип
Ох уж эти бедные люди, у которых вечно всё падает без строгой типизации. Почти все эти ваши интернеты на языках без строгой типизации крутятся-вертятся, а у вас всё падает бесконечно вечно.
Ты тупой?
> Вы выбираете одно из двух - либо настоящий messaging, либо строгую типизацию известную на этапе compile-time
>Ты тупой?
Нет, просто пытаюсь понять что ты накарябал.
А каким образом CLOS позволяет сочетать и true-мессаджинг и декларацию типов? И эта декларация типов позволяет ведь делать статический анализ? А то речь именно про это.
CLOS - это и есть мессаджинг. Декларации типов - это ортогональная фича, она позволяет компилятору оптимизировать свой выхлоп, вставляя специфичные операции вместо вызова generic-функций. Окей, я покривил душой, декларации типов не делают CLOS быстрее, если только не использовать очень специфичные и хрупкие костыли вроде inlined-generic-function, но, по крайней мере, код, не использующий CLOS, декларации типов определённо ускоряют.
> И эта декларация типов позволяет ведь делать статический анализ?
Что ты подразумеваешь под "статическим анализом"?
>Что ты подразумеваешь под "статическим анализом"?
Анализ кода без его запуска.
Дроч на статическую типизацию - он про это, что у тебя есть инструмент проверки корректности программы хотя бы по типам. Ну типа строку вместа числа не передашь как в петухоне.
Для того чтобы такой анализ был возможен - нужно чтобы тип значения в принципе был вычислим статически. Существует класс языков с сильной типизацией, сильная или типизация по Хинди-Милнеру означает как раз возможность вычисления типа в любой точке программы. За счёт этого можно гарантировать формальную корректность. Такие языки - это OCaml, Rust, Haskell, Scala, ну и ещё множество.
С другой стороны есть actor-model язык с ООП по Алану Кею, где есть messaging. Суть его в том, что любой актор может послать другому актору вообще любое сообщение в рантайме. Понятно что это не вычисляется статическим анализом. Есть иснтрументы для сужения множества допустимых значений в конкретных точках программы, например на выходе из функции, но в целом парадигма messaging противоречит статическому анализу.
> Ну типа строку вместа числа не передашь как в петухоне.
Смотри пикрелейтед. Два два восемь, всякое разное курить не бросим.
> Анализ
По-прежнему не понимаю, что ты вкладываешь в это понятие. Кто анализирует-то? Человек? Компилятор? Рантайм?
> Существует класс языков с сильной типизацией
В CL сильная типизация, но не Хиндли-Милнер.
Ещё раз повторюсь, CL успешно смешивает две упомянутые тобой концепции за счёт их ортогональности. Ну и за счёт лингвистической абстракции можно изъебнуться и сделать messaging, но работающий на этапе компиляции, типа как в C++ - см. inlined-generic-function и fast-generic-functions.
>По-прежнему не понимаю, что ты вкладываешь в это понятие. Кто анализирует-то? Человек? Компилятор? Рантайм?
https://www.erlang.org/doc/man/dialyzer.html
Настраиваешь анальную проверку диалайзером в CI/CD и он тебе анализирует код и не позволяет вмержить/задеплоить код, не прошедший проверки
Мимокрокодил
А, понятно, отдельные костыли-костылики. Неясно, почему такое не встроить в компилятор.
> сильная или типизация по Хинди-Милнеру
Ебать
> означает как раз возможность вычисления типа в любой точке программы
Ты
> messaging. Суть его в том, что любой актор может послать другому актору вообще любое сообщение в рантайме
Несёшь
> парадигма messaging противоречит статическому анализу
Хуйню
Во-первых, сильная и слабая типизация не означают являются ли они HM или нет, почитай википедию. Во-вторых, в Rust не HM. В-третьих, HM не означает что в любой точке можно вывести тип. Его вообще далеко не всегда можно вывести из-за проблемы остановки.
В-четвертых, акторная модель и посылка сообщений никак не противоречит статической типизации. Посмотри на Gleam или Scala Akka. В-пятых, статический анализ это просто анализ кода, это не только проверка типов
>>2456083
В Elixir есть проверка типов в компайле. Просто она не такая развитая как у каких-нибудь Rust или Haskell, но зато более развитая чем у C. Во-первых, есть встроенный тайпчекер. Во-вторых, есть Dialyzer или Gradualizer (второй скорее экспериментальный). Но сам язык всё равно динамически типизированный. Если хочешь прям именно статическую типизацию, которая будет ебать мозг, когда тайпчекер не сможет вывести тип, иди в Gleam.
>>2455861
> эликсир будет в рантайме проверять что мы передали структуру, а не строку или булеан?
Да, виртуалка будет проверять. Но это не потому что разрабы обосрались, а потому что Erlang (и, как следствие, Elixir) умеют иметь общий неймспейс в кластере. То есть, я могу собрать несколько инстансов программы, разделить их сетью, и уметь из одного инстанса работать с данными на другом. И поэтому тут может быть рассинхронизация версий софта, из-за чего могут быть разные данные. Поэтому тут обязательно нужна динтипизация с тэгированием данных, иначе инстансы с разными версиями программы не смогут общаться.
Ну, и ещё динтипизация нужна для Hot-Reloading, чтобы можно было обновлять код не останавливая систему.
> Если это так, то как на нём пишут высоконагруженные системы, когда всё может упасть из-за того что в функцию передали не тот тип?
Не слушай чуваков выше, которые говорят, что динтипизация ускоряет прототипирование и всё такое. Ни-ху-я. Весь Production grade код на эликсире обычно написан с аннотациями типов и всегда проверяется тайпчекером на наличие ошибок. Как я уже написал выше, в функцию может спокойной прилететь не тот тип не из-за ошибки разработчика, а из-за какой-нибудь проблемы в распределённой среде. Всё-такие Elixir (как и Erlang) это языки для распределённых систем
Динамическая типизация про то, что типы проверяются в рантайме, а не при компиляции. То, что ты описал, это следствие того, что а. петухон -- императивный б. динтипизированный язык.
Я тоже охуел на третьем курсе вуза, когда узнал, что лисп это динтипизированный язык, но потом понял, что я все это время ошибался.
Не сложно, у нас тут не такой лютый фп как в хаскелях. По большому счету, нужно вкатиться в иммутабильность и, что чуть сложнее, в эти наши OTP и модели акторов. Но когда все эти дела осознаешь, то поймешь, что язык пиздос какой простой на самом деле. ООП вермишель в 10 раз сложнее распутывать.
А что там такого в хаскеле сложнее по сравнению с эликсиром/эрлангом?
Акторы и обмен сообщениями, если я правильно понял, чем-то немного напоминает каналы в го и обмен между горутинами. Я почитал про философию языка, и мне понравились некоторые концепции, но пока вся эта байда с супервизорами не понятна, такое ощущение, что над самим приложением язык какую-то очень сложную надстройку создаёт для управления и мониторинга, в которую надо вникнуть, чтобы что-то запустить вообще.
Начну тогда наверно со ссылки в оп-посте, где только упражняться не понятно. На литкоде даже нет его, чтобы задачки порешать и к синтаксису привыкнуть.
В хаскеле ты одной строчкой можешь написать то, на что в элике у тебя уйдет 10. Соответственно за подобную абстрактность нужно платить, прилагать больше усилий для понимания и написания кода, ну и распутывания, если не ты писал.
мимодиван
А почему советуют эликсирскул, а не оф туториал?
Забавное
Erlang State of Mind
Erlang State of Mind
Erlang State of Mind
Треды жрут мало памяти, говорили они.
Там та же проблема что и с говяхой, происходит аллокация небольшого кусочка памяти для каждого потока, потому что ты наверняка будешь что-то там делать. В пустых задачах это бесполезно смотреть.
>В хаскеле ты одной строчкой можешь написать то, на что в элике у тебя уйдет 10.
Я не понимаю, как на это можно серьезно дрочить, имея больше половины функционирующего мозга. В Си любую программу можно написать в одну строку, но там это типа считается дурным тоном, а вот Хаскель это дааа, мы будем писать все в одну строчку, потому что у нас язык типа такой выразительный. Когда-нибудь до них дойдет, что если открыть код любой программы на любом языке, то он будет выглядеть как одна линейная последовательность символов.
Ну ладно, я юродствую слегка, конечно. В Хаскеле проще писать все одним выражением, чем в других языках. Но спрашивается, нахуя? Во-первых, еще под большим вопросом, что это более читаемый стиль, во-вторых, редактировать это точно заебнее. Потому что когда у тебя сложное выражение разбито на несколько строчек, то тебе в среднем асимптотически меньше шагов нужно сделать, чтобы добраться до нужного подвыражения. Просто задумайтесь, сколько шагов вам понадобится в среднем, чтобы из случайной клетки А попасть в случайную клетку Б если клетки организованы в список размера NxM и если они организованы в матрицу NxM. Подсказка: O(NxM) и O(N+M) соответственно. В-третьих, что самое главное, на отладке ты из-за своих однострочников пососешь хуй.
Вот написал я в функциональном языке программу, где есть инпут, который проходит через фильтр, мап и фолд. Где я могу обосраться? Я могу обосраться в: 1. лямбде фильтра 2. лямбде мапа 3. лямбде фолда 4. при передаче результата фильтра мапе 5. при передаче результата мапа фолду. Если я написал однострочник, все эти пять точек отказа вырождаются в одну, и понять причину ошибки можно только тупым перебором инпутов. Если же я дал биндинг/переменную под каждую лямбду и каждый промежуточный результат, причину ошибки выяснить на порядок проще, я сразу знаю, какие узлы графа вычисления дали некорректный результат.
Можно конечно по быстрому превратить однострочник в многострочник и отладить, а потом превратить его обратно в однострочник, но это цирк с конями, лучше уж тогда сразу писать отлаживаемый код.
Ничё не было, я пошерстил свои чаты — группа давно удалена, и в истории нихуя инетерсного там не было.
У айтишников? Мы же говорим про айтишников, а не про вась, у которых вообще в голове что угодно может быть
CPU-bound - работает плохо, хуже чем в питоне, IO-bound очень хорошо, лучше чем везде.
https://github.com/DockYard-Academy
Я не ОП, но могу вставить свои 5 копеек.
- свои легкие процессы в user space - быстро запускаются, мало жрут
- распределенность из коробки
- акторная модель из коробки (если нужна, нужна не везде)
- supervisor
- горячее обновление кода
- возможность дебага работающего процесса, хорошая интроспекция
Всё это можно реализовать в других языках. Но так можно сказать и про многие фичи других языков. Но дело в том, где это достигается быстрее и проще
>свои легкие процессы в user space - быстро запускаются, мало жрут
>распределенность из коробки
>акторная модель из коробки (если нужна, нужна не везде)
>supervisor
Все плюсы перечеркиваются когда нужно добавить немного CPU нагрузки. Поэтому BEAM подходит только для чистой IO нагрузки типа реббита или чатиков дискорда.
Немного CPU нагрузки по определению не могут ничего перечеркнуть.
Кроме того можно вызывать сошки (https://www.programmersought.com/article/92537823822/), можно выделить CPU-bound tasks в отдельный microservice.
>можно выделить CPU-bound tasks в отдельный microservice
И зачем нужен элексир если подразумевается, что все равно придется реализовывать микросервисную архитектуру и инфраструктуру от нее?
>CPU-bound - работает плохо, хуже чем в питоне
Не правда же.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/measurements/erlang.html
Он наркоман. В прямом смысле. На конференциях выступал под кайфом. Ну и все остальное в придачу. В общем, полный неадекват.
>гейскими
Гомосексуализм не норма, а извращение. Сегодня ты называешь нормой гомосексуальный половой акт, а завтра скажешь, что половой акт с трупом тоже норма. Посмотри на себя со стороны. Ты отвратителен. Ты безумный.
https://paraxial.io/blog/elixir-savings
пиар какого то очередного ненужного говна
Промо хуйня.
>Почему вы выбрали Эликсир?
>Потому что Эликсир это суперкрутой, супрепроизводительный язык.
>Как вам помог Эликсир?
>Он нам сэкономил $100,500.21 денег.
Ни технических подробностей, типа один инстанс раньше выдерживал 15 RPS, а теперь 15000.
Ну и в фразе:
>Rewrote an #AWS APIGateway & #lambda service that was costing us about $16000 / month in #elixir. Its running in 3 nodes that cost us about $150 / month.
ключевое
>Rewrote an #AWS APIGateway & #lambda
Только дебилы пишут хайлоад на AWS Lambda, AWS Lambda это развод гоев на шекели. Единственный случай когда AWS Lambda может быть оправдана - это 1,5 запроса в сутки, тогда да, это будет дешевле. Если бы они переписали все с нормальной архитектурой на любом современном языке, они сэкономили бы ± столько же шекелей.
ввожу %, крашится сервер, не перезапускается, нужна перезагрузка редактора
прикольно сделали, приду ещё через года 2
Какой плагин? Там их два: заброшенный и рабочий, и ты походу выбрал не тот.
> Мне подсовывают полиморфизм, который выглядит точно также, как и эти ебаные классы, интерфейсы и прочий кал(структуры, протоколы, бехейверы и т.д.)
Полиморфизм это не ООП, анон. Интерфейсы это тоже не ОПП. В Elixir, например, нет наследования, нет инкапсуляции, нет объектов (как данных с закрытой структурой). Если полиморфизм и интерфейсы это ООП, то любой Lisp это ООП язык
> А в вашем языке даже синтаксис почти как в си-лайк параше всякой
Ну во-первых ты реально тупой, если языки по синтаксису оцениваешь. Во-вторых, он от C довольно далеко. У них с C общие из синтаксиса, наверное, только инфиксность и запись вызова функций.
