вот оч старая демонстрация как передать етс другому процессу https://github.com/DeadZen/etsgive

Всем привет! Мы проводим небольшое исследование по критериям поиска работы IT-специалистами. Буду признателен за заполнение анонимной анкеты (займет не более 5 минут): https://forms.gle/bT3sBdYP8Fh2aVMK6

+

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

после чего задать вопрос про отмечание топ-5.

https://github.com/flussonic/openapi_handler

первичный релиз openapi handler.  Перенесем примеры скоро.

Почему не data_dir, например? https://github.com/flussonic/openapi_handler/blob/4d80477e16cf0361e3949916481e3257504c12ce/test/openapi_collection_SUITE.erl#L28

без особой причины

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

Как же надо изнасиловать свой мозг какими-то химерными конструкциями, чтобы всерьез считать, что реконфигурация через code upgrade — это что-то разумное:  https://erlangforums.com/t/what-do-you-think-should-be-in-otp/556/64

code upgrade в эрланге вообще сделан так, что им пользоваться чрезвычайно сложно. А говорить об этом как об инструменте для реконфигурации — просто глупость

Интересно, раньше Erlang пытались натягивать на OOP,
теперь, похоже, следующая волна зелотов будет пытаться
делать из beam kubernetes

С kubernetes подходом эрланг нахер не уперся. Есть куда более развитые и удобные языки.

Любим то мы за то, что можно не рестартить.

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

не, точно парад ламеров в коментах

Ну если процессы полноценного обновления кода (через otp, релизы, с тестированием и тд) на горячую поставлены, то почему бы и не использовать их для реконфигурации?
Другой вопрос, что такой подход будет стоить как космос, и работает он, подозреваю, в лучшем случае только в Эриксоне.
Вообще похоже не разговор теоретика с практиком😁

Я не готов всерьез обсуждать с кем бы то ни было процесс горячего обновления кода в эрланге.

Безумное перекладывание полей по номерам - это кошмар любого руководителя разработки.

Фантастически дорого, почти не тестируемо и просто бесчеловечно, по-садистки неудобно.

Речь же идет о том, что в эрланге в принципе нет миграций в стиле sql.

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

Короче:
- напиши распределенную map reduce функцию для апдейта этого поля
- кажется ты меня послал куда подальше

Да. К тому же вопрос обновления версии ерланга все равно никак не решить без остановки

> Let’s better don’t continue it in public area, unless we don’t want this thread to be shared on golang community.

А у этого чата есть цитатник?

Я не понял этой шутки

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

И в результате получается: в эрланге проблемы (скорость работы и отсутствие типизации и, соответственно, частые незаметные поломки кода на средних и больших проектах при изменениях), и источник этих проблем - это горячее обновление кода, которое по факту никому не нужно😕

А мне кажется, что желание менять mfa чайлда в супервизоре это какая-то лажа, потому что
1. Супервизор нужен как раз чтобы запускать процесс в валидном состоянии. То есть, можно изменить mfa таким образом, чтобы чайлд не стартовал. Это плохо
2. Нужно тогда будет менять состояние каждого супервизора прямо до корневого. Что и будет глобальным состоянием, только совершенно имплиситным и неконтроллируемым
3. Есть 1000 и 1 способ как решить эту проблему без глобальных состояний и всего такого

дин типизация еще и из-за межнодной коммуникации

Зачем? Кто мешает сделать статически типизированные каналы и при межнодовой коммуникации?