Supervisor.start_child(MsinSup, SomeAgent, {Agent, :start_link, [ как там он инициализируется а забыл ] }, что там ещё надо я забыл)

из любого места, в любой супервизор так можно засунуть вообще левого чайлда

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

это костыль правда . )

Валидация данных не должна крэшить процесс далее, чем первые стадии рапид прототайпинга.

про валидацию я хз, если не должна — то try/catch и возвращать тупл {ok, ...} / { error, ...}

Либо ловящийся try rescue с обработкой и выдачей, что конкретно не так в данных, либо такая же ошибка, но выдаётся как ok / error тупл.

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

ETS медленнее мапы в стейте, а в БД только совсем важные данные, которые должны переживать падение вообще всей виртуальной машины BEAM

про валидацию я хз, если не должна — то try/catch и возвращать тупл {ok, ...} / { error, ...}

Ага, я так и делаю обычно

либо оно прокидывается выше где все равно ловится

ETS медленнее мапы в стейте, а в БД только совсем важные данные, которые должны переживать падение вообще всей виртуальной машины BEAM

Для тех данных, что должны переживать падение процесса - ETS это достаточно быстро.

Для тех данных, что должны переживать падение процесса - ETS это достаточно быстро.

в общем случае это неверно, но допускаю, что почти всегда верно. Но опять же таблица в ETS подыхает вместе с процессом ее создавшим (или я ошибаюсь?), а значит опять городить костыли.

Таблица ETS создаётся одна на всех подобных клиентов.

в общем случае это неверно, но допускаю, что почти всегда верно. Но опять же таблица в ETS подыхает вместе с процессом ее создавшим (или я ошибаюсь?), а значит опять городить костыли.

у ETS есть heir.

Процесс сам не умрёт по той простой причине, что он ничего делать не будет.

И это не костыль.

или вообще в топлевел супервизоре ее создать

Процесс сам не умрёт по той простой причине, что он ничего делать не будет.

А тогда зачем ETS? Если процесс не умрет, то пусть в своем стейте и держит

Не умрёт процесс, который держит ETS и ничего более не делает.

Ему и свой стейт не нужен, потому что он ничего не делает кроме как держать ETS.

Это я понял

но генерить множество ничего не делающих процессов, как-то претит мне, как бывшему плюсовику. "Надо себя заставить, братан" (с)

в эрланге это норма, ибо относительно дешево

Мне такое чувство, что все кто хают let it crash в чяте тупо не дочитали доку про supervision trees и child specs

+. Но дело в другом, даже если знают о супервизорах, не понимают философии до конца.

Eugene У тебя как в OS при старте VM - уже 30+ легковесных процессов будет всяких там от kernel для работы с сетью, io и так далее. Так же и сложная аппликация ещё как минимум столько же создать просто необходимых для работы этого приложения.

Мне такое чувство, что все кто хают let it crash в чяте тупо не дочитали доку про supervision trees и child specs

Прочитали и даже используют. Возможно я неверно трактую let it crash

Let it crash проще объяснить на людях. Если прораб посылает рабочего рыть тоннель, то рабочий сам не в состоянии обработать исключение, возникающее при обвале. Это задача прораба - расхлебать. А сам рабочий - let it crash.

И если информация, которую прораб хранит настолько важна, что не должна потеряться при обвале - ему нужна рация, чтобы он её сообщал в другое место.

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

*рабочего

Я про рабочего писал.

Да, я понял. Просто расширил дерево супервизирования. ?

А если офис ночью могут внезапно снести, то ....

Let it crash проще объяснить на людях. Если прораб посылает рабочего рыть тоннель, то рабочий сам не в состоянии обработать исключение, возникающее при обвале. Это задача прораба - расхлебать. А сам рабочий - let it crash.

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

при этом прораб по-бырому рожает еще одного рабочего

безысходность какая то

Да все ок. Мы просто уже в крайности пошли

в этой истории нехватает только взрывов на заднем фоне

Не может это не работать совсем, когда куча людей счастлива и только наш боярский чатик недоволен

безысходность какая то

жизнь - это боль

Не может это не работать совсем, когда куча людей счастлива и только наш боярский чатик недоволен

Куча людей довольна российскими сериалами про лубоф и похапе. Не боярское это дело.

а есть какой то патерн , сохранения всех эвентов перед тем как начать с ними работать и последующим востановлением стейта по ним ?

у gen_server

по типу akka persistence

ну наверное можно перед смертью сохранить стейт, а потом восстановить, но очередь сообщений теряется восстановлению не подлежит

Скажем так, let-it-crash в эрланговском исполнении позволяет делать системы с девятью девятками аптайма. Если количество девяток представляет какую-то ценность для вашего бизнеса - то эрланговский let-it-crash показывает правильный путь к решению. Никто не говорит, что девять девяток - это просто. Это высший пилотаж, конечно. Но есть ли, с чем сравнивать? Просто есть определённые ценности и ориентиры: стабильность времени ответа, аптайм... BEAM ориентирован именно на них. Хотите всего этого - осваивайте.

а лучше, как тут люди советуют, вообще стейт вынести подальше от камнепадов

А, ну ещё смузи в Рокете. ?

Но это в экосистеме не от рождения.

А, ну ещё смузи в Рокете. ?

А еще норы и PS4 в комнате отдыха

defmodule MyApp.Server do use GenServer # ... def init(_) do Process.flag(:trap_exit, true) state = MyApp.Backup.fetch_state() {:ok, state} end # ... def terminate(_reason, state) do MyApp.Backup.store_state(state) end end

В Эликсире ещё и Task есть.

А еще норы и PS4 в комнате отдыха

Я кстати так и не понял когда в нее играть. У меня на работе просто была пс4 но это как-то не очень садиться и играть

неделя перед новым годом самое то

Недавно слышал мнение, что командные видеоигры очень повышают способность программистов к эффективной командной работе. Но я не уверен, что PS4 подходит. Вероятно, речь о чём-то тактическом.

Вероятно, игра в страйкбол работает так же, только гораздо дороже и реже.

Alexey trap exit необязателен, если State хранится выше по дереву супервизирования.

И, собственно, он же будет trap exit-ом только для тех процессов, с которыми слинкован.

Я просто сначала не совсем понял, для какой цели он здесь.

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

ну скорее как пример. В тех же рельсах джобы в сайдкике тоже могут грохаться, а потом уходить в retry

не понимаю в чем проблема let it crash

ну скорее как пример. В тех же рельсах джобы в сайдкике тоже могут грохаться, а потом уходить в retry

джобы это не long-running таски, не совсем корректно их с генсерверами сравнивать

Где-то приводился пример на основе серверов. Зашел ты погуглить - гугл упал. Обновляешь страничку, ждешь когда оживет. Ожил - получил данные

в этом случае речь про application server'a, скорее, вернее про процессы/треды в них и если там вылетел эксепшн, то они обычно просто перезапускаются по отдельности. но ведь они не держат в себе какой-либо стейт в отличие от генсервера. не будешь же ты расчитывать на хранение данных в памяти в треде/процессе пумы/юникорна, например

Но реальность будет такая

ERROR: S client not available

Зачем в чайлдспеках может пригодится значение :brutal_kill?

Родил процесс и сразу убил? Зачем?

а дошло

это значит, что после того как будет отдана отмашка сдохнуть, супервизор не будет ждать пока процесс обработает завершение и сразу его прибьет, я верно понял?

"клиент уползает с поломаными ногами, а ты делаешь вид что вообще ничего не произошло" - Ну здесь архитектурная ошибка.... Вот у нас в системе до сих пор, иногда заглянешь в логи, а там крэши, но большую часть кршей конечные пользователи не замечают никак. Потому что let it crash - помогает сделать архитектуру так, что непредвиденные и разные не пойманные ошибки никак не влияют на конечный результат. Что-то рухнуло, перезапустилось, обработало пользователь конечный вообще ничего не заметил.

Суть в конечном итоге, что let it crash философия сводится к тому, что пиши свою систему так, что в случае непредвиденных ошибок - она будет все равно работать и дает механизмы для построения подобной системы. Поэтому не понимаю критики в данном случае. П.с. от непонимания оной - один участник чата уже свалил)

все-таки эликсир пересахарен

(fn(x) -> x end).(a: "a", b: "b") тоже самое что и (fn(x) -> x end).([a: "a", b: "b"])

ватта фак?

точнее я знаю что за фак

вопрос нафуя?

ответ: раби

вопрос: а что руби-то? предполагаемый ответ: перл

ответ РГМ - руби гойловного моска

вопрос нафуя?

Чтобы методы вызывать?

скобки поставил - ничего не поменялось - норм так

Eugene : Передавать именные аргументы в функцию последним аргументом красиво:System.cmd("ls", [], env: [{"TEST", "test"}], cd: "/") вместо: System.cmd("ls", [], [env: [{"TEST", "test"}], cd: "/"])

Интересно форматтер это исправляет или нет

я знаю, как эта херь работает

каждую неделю новый синтаксисобатхерт. не надоело?

Интересно форматтер это исправляет или нет

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

ruby: def foo(x, hash={}) foo("blah", a: 12, :b => 13)

@sdzyba : Убирает форматтер, хорошо.

есть мнение что если тебе не нравится по каким-то причинам сахар, то можно просто молча его не есть

Интересно форматтер это исправляет или нет

уберет

тем более что есть lfe, alpaca просто erlang в конце концов

@nitrodev Проверил тоже, уже.

тут не только вызов функций оно везде так работает. просто неконсистентность. есть a. Список из одного элемента a будет [a] есть a: "a", b: "b" - список из двух кортежей. [a: "a", b: "b"] - список списков кортежей? А вот и нет.

Я только что искал ошибку, неправильно чайлдспеки из-за этого написаны

Eugene Помойму все консистентно. : - позволяет убрать [ скобки

Если нужен лист в листе, то [[a: "a"]]

Никакие скобки автоматически нигде не добавляются, просто их можно не писать, если : ни них уже указывает.