Автор: Дмитрий Коваников · Podlodka Podcast
Дмитрий Коваников — Senior-разработчик в Bloomberg и практикующий Haskell-программист. Он приходит в разговор о конфигурационных языках не как DevOps, а как человек, который думает о типах и корректности программ.
YAML победил как конфигурационный формат не потому что хорош, а потому что лучше XML и JSON для человекочитаемых конфигов. Но у него есть фундаментальная проблема: он динамически типизирован и разрешает неявные преобразования. «Norway problem» — это не анекдот, а реальный баг: NO в YAML интерпретируется как булев false, и код страны Норвегии превращается в логическую ложь без единого предупреждения. TOML решает часть проблем, но не даёт ничего похожего на статическую проверку. Dhall — типизированный функциональный язык конфигурации — задаёт другой вопрос: а что, если конфигурация была бы верифицируема до деплоя?
Кому смотреть: backend-разработчикам и DevOps, у которых есть большие YAML-конфиги с логикой внутри — якоря, шаблоны, условия — и которые замечали, что ошибки в конфигурации бывает сложнее поймать, чем ошибки в коде.
Из этого можно взять в работу: найди самый большой YAML в своём репозитории и посчитай, сколько там логики — якоря, merge keys, шаблоны. Это ровно та часть, которую Dhall мог бы сделать верифицируемой.
Выпуск строится вокруг конкретного сравнения трёх форматов. YAML — самый распространённый, но с историческим грузом: неявные типы (строка true — это булев true), чувствительность к отступам (tab вместо пробела — валидная причина сломать деплой), сложные правила наследования через якоря. Большинство людей, пишущих YAML, не знают всей спецификации — и это нормально, пока не нарывается на edge case.
TOML — сознательная реакция на сложность YAML. Он проще, явнее, типы более предсказуемы. Хорош для конфигурации программ (Cargo.toml, pyproject.toml), но не масштабируется на сложные иерархические конфиги и не даёт никаких гарантий корректности.
Dhall — это отдельный разговор. Это не просто формат, это функциональный язык с системой типов, где конфигурационный файл можно проверить статически до того, как он попадёт в production. Impure операции (обращение к сети, чтение файлов) намеренно запрещены — Dhall-файл детерминирован по построению. Дмитрий объясняет это через призму хаскелевского мышления: если у тебя есть тип, ты не можешь положить туда невалидное значение.
Практический порог входа в Dhall высок — нужно освоить незнакомый синтаксис и непривычные концепции. Но для организаций с большими, сложными конфигами, где ошибки стоят дорого, это может быть обоснованным выбором. Разговор честный: Дмитрий не продаёт Dhall, он объясняет, когда он имеет смысл.