Есть разница. Опубликованая вакансия - - это приглашение к разговору. А письмо в личную почту приходит без приглашения.

Я отвечаю часто, но не всегда.

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

Сперва собеситься, при наличии офера решать

внесу больше ясности: пишут на Линкедин с релокацией. я не готов так сразу рассматривать это предложение: мое положение не настолько затруднительно, чтоб хвататься за соломинку - раз; по некоторым причинам я не готов к релокации в Европу - два; но вдруг это работа мечты - три. поэтому я предпочитаю сначала навести справки.

С вашего позволения немного разбавлю дискуссию про дела эйчарные вопросом про дела технические. Как-то так сложилось, что никогда задумывался как по-уму делать RPC между микросервисами в случае эрланг кластера (как-то всё http использовалось), т.е. как правильно это организовать, чтобы можно было балансировку между нодами иметь из коробки, обработку недоступности нод ну и т.д. Может какие уже готовые библиотеки есть? Поделитесь опытом, кто такие вещи уже делал/использовал.

Обязательно пиши. Проактивность приветствуется и вообще, хороший тон.

подобное сейчас модно решать sidecar proxy разного рода, в т.ч. для http
ну и как всегда можно заменить http на очереди/кафку

по набору фич или по нагрузкам? ростелеком инведион бредбери - или у них не сс?
сколько вообще сейчас ерланговский сервер трансляций тянет? в ранних докладах я читал 2К ты говорил

Модно-то модно, но есть предположение, что на чистом эрланге можно сделать заметно проще, за счёт исключения этапа конвертирования типов данных между транспортом (http + json или вроде того) и внутренней логикой сервисов. Плюс в доверенной зоне можно минимизировать валидацию данных.

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

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

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

перфоманса - да, выиграешь чутка

особо тут не сэкономишь

Ну вон в риаке совместимость между парой версий есть, и не сказать, что там для этого много кода.

Есть цифры?

между нодами у эрланга общение в один процесс

если в новых версиях ничего не поменялось

то есть это узкое место