Их можно миксовать вообще на уровне модулей

Я не про то что это инновационная инновация, а про альтернативу переписать все и сразу

Поэтому и называется mix ;)

Я вообще начал ставить чистые erlang проекты
под mix только для релизов,
чтобы иметь нормальный
пользовательский конфиг.

а какой там конфиг?

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

там какой-то код парсинга до старта запускается?

Тебе будет интересно самому разобраться, но странно что ты это пропустил

используется "старая-добрая" схема от Basho:
- загрузка приложений, чтение базового sys.config(в данном случае release.conf)
- запуск конфиг-провайдеров, мердж их конфигов с базовым
- скидывание получившегося конфига на диск
- init:restart с этим конфигом

а именно?

Возможно, @prepor знает ответ

Я кстати до сих пор не понимаю, как он знает какие апы запускать а какие - нет

Да, и плюс к ответу Владимира - сделали это очень удобно, что можно любой код подключить, взял toml, написал свой. В общем, стало очень просто любой формат конфига подключать.

Не устраивает, но как говорится, что есть.

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

Норм живут, кейсы, которые решает статическая типизация в нынешних мейнстримовых языках настолько примитивные, что они все закрываются практически бездумными юнит-тестами and/or генеративными тестами. При этом не принося с собой ничего полезного, они очень негативно влияют на возможности программировать, начиная от локальных сложностей (когда или система типов оч примитивная и приходится городить фабрики фабрик чтоб в нее засунуть нужное или собирать паззлы из теории категорий и GADT, если не примитивная) и продолжая сильно ограниченными возможностями существования в открытой экосистеме, т.к. ЯП со статической типизацией всегда стремятся к CWA (Closed World Assumtion), просто тупо по определению (и потому что так проще). Как бонус долгая компиляция.

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

Но это теоретизирование. Понятно, что когда удаляешь поле из структурки, а редактор тебе такой сразу "братуха, ты ж вот тут из нее читал, чот не то" это приятно и удобно. И это работает здесь и сейчас. А без статической типизации хоть фундаментально и ничто не мешает иметь такой же фидбэк "от редактора", но никто так не умеет сейчас. Мне кажется это больше исторический артефакт, "так получилось", чем какой-то осмысленный прогресс именно в эту область.

вот да, 95% отдачи это "а тут у тебя филд используется"

А вообще - это была ситуация, где юниор сказал, что готов готов сделать PR, "только диалайзер ошибки выдаёт". А выяснилось, что диалайзер то нашёл реальные ошибки и если бы юниор свой код хотя бы протестировал бы, то я бы столько не дебаггил бы ошибки диалайзера. Поэтому, когда поправляешь диалайзер ошибки после тестов - тратится где-то всего 1-2 часа на каждый PR.

> редактор тебе такой сразу "братуха, ты ж вот тут из нее читал, чот не то"

А в каких языках такое не работает? js да, elixir да, python да. Из того что использую...

ну ты сейчас про статический анализ кода эликсира диалайзером?

У всех что-то есть, всякие langage server ы которые что-то проверяют там