Для конфигов внутреннего употребления главный, на ...
# russian
o
Для конфигов внутреннего употребления главный, на мой взгляд, аргумент – поддержка IDE. Она уменьшает необходимость в документации (completion is ok), уменьшает вероятность выложить неработающий совсем конфиг (баги всё равно будут, но хотя бы ошибки DSL будут подсвечены прямо в IDE), удобство использования того же DSL в тестах (если тесты на Kotlin, конечно, но это так и должно быть, да же?). При дополнительных усилиях DSL конфигов строится прямо на базе публичного API той подсистемы, которую он конфигурирует, что позволяет избежать рассинхронизации и уменьшить вообще количество кода специально для конфигурации, чаще всего достаточно билдерных функций, которые по сути оборачивают
ConfigClass().apply(configuration)