Так процесс — это объект по Кею. У него есть инит и стейт.

вот

Ну да, то что я и говорю. Можно сделать DI в генсервер, но не в модуль же

Для этого нужно чтобы это происходило в рантайме, да, а все инклуды и импорты — это компайл-тайм.

А я что-то не заметил, чтобы apply в среде elixir сильно жаловали.

эрланг ооп язык же, почему вы не хотите говорить про ооп

да это я путаюсь в терминах, скорее всего. короче! суть di в том, что потребитель некоего сервиса может себе позволить не знать откуда этот сервис взять. то есть просто использует его не заботясь о наличии, так? вроде так. сам сервис при этом может себе позволить не знать, кто его использует - он просто существует. так? и тут вроде так. тогда суть di сводится к тому, что бы в какой-то момент времени собрать потребности, и туда где эти потребности есть поместить то, что эти потребности реализует. в любом виде - в виде ссылки, или id в каком-то менеджере сервисов, и так далее. как это могло бы выглядеть в эрланге вопрос открытый, но кто мешает, скажем, в compile time все обращения к, к примеру, gen_server превратить в проксик, в который можно завернуть хоть оригинальный gen_server, хоть любую другую реализацию? интерфейс-то у них один и тот же

где я много наврал? :)

Ну да, здесь получается важное отличие от просто конфига
Ты не знаешь, где взять зависимость свою

Мне просто кажется что во всяких там «ооп» жабоподобных очень плохо и дорого с макросами и рефлексией, поэтому там придумали такую кухню.
В «других языках» модуль может и сам знать на этапе компиляции, откуда ему брать зависимости эти самые. Другое дело - как это все писать.

Если логгер не написан в Эрланге через интерфейс - то хрен что сделаешь уже

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

самый популярный жабный di фреймворк Spring работает на той самой рефлексии, собирает зависимости в рантайме на старте приложения  и отлично себя чувствует

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

Все равно каждый модуль должен задекларировать «мне нужно то-то и то-то» иначе никакой сверхразум этого не поймёт

А если так - то разницы между «я скажу сверхразуму что мне нужно» или «сверхразум спросит у меня что мне нужно» я не вижу

ну всё именно так.

ещё важный момент — тот, кто пользуется этим кодом _полностью_ контролирует, что именно будет этот код дергать.


Так, например, классический код на реакте — плохо тестируемый хлам, потому что его только мокать можно.

Код на ангуляре все внешние зависимости явно декларирует и просит ему их передать

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

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

ну, или если обнаружит две и более реализации генсервера, то не взлетит с ошибкой "слишком много вариантов для внедрения зависимости, я не знаю что делать" :D

Это какая-то волшебная магия.