Ну так это будет тоже маппер, просто промежуточный

raw data ->(map) key-value ->(map) final config

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

ладно, пока попробую с Variant, чисто ради эксперимента, если совсем будет тошно, то тогда буду пробовать что-нибудь то, что писали выше. Спасибо всем откликнувшимся.

там можно any кастить к запрашиваемому типу, либо просто уже объекты формировать нужного типа на капждую настройку (кодеген, миксины)

кто-то тут писал, что в Rust все прекрасно с асинхронностью. И как в расте сделана асинхронность?
async/await проимисы и фьючерсы?

В расте...

это вряд ли так

А как?

футуры это и есть промисы

плохо

ну, в традиционной терминологии нет.

вообще асинк в расте самая ужасная его часть. на него жалуються все кому не лень

раст нетрадиционный

А, ну ок.

Может в этом и есть его залог успеха... успеха точнее пока что нет, но есть задаток на успех :)

ну пока что это только хайп)

но может быть когданибуть...

Хайп один из залогов успеха