Abstraction, not syntax
В статье обсуждается, что главная проблема конфигурационных файлов — не синтаксис, а отсутствие абстракций. Хотя многие ругают YAML за сложность, реальная проблема в том, что даже простые форматы вроде JSON не решают проблему дублирования и ошибок вроде опечаток в числовых константах.
Автор показывает на примере: если нужно описать несколько однотипных ресурсов (в примере — cloud-бакетов для бэкапов), то даже в JSON или YAML придётся дублировать код, что ведёт к ошибкам. Например, в одном месте указали 2592000 секунд (30 дней), а в другом — 259200 (пропустили ноль), и из-за этого данные удаляются через 3 дня, а не 30.
Решение — использовать язык конфигурации, который поддерживает абстракции, как в языках программирования. Например, RCL позволяет использовать переменные, циклы и вычисления, что исключает ошибки из-за опечаток и дублирования. Так, вместо шести повторяющихся блоков конфигурации можно написать один цикл, который сгенерирует их все, гарантируя, что все значения согласованы.
Хотя некоторые форматы (как HCL) тоже поддерживают выражения, важно, чтобы их хватало для полного устранения дублирования. Поэтому при выборе формата конфигурации стоит смотреть не только на синтаксис, но и на возможность абстракций.
Комментарии (51)
- Обсуждение в основном вращается вокруг того, что конфигурационные языки (YAML, JSON, TOML и т.д.) не масштабируются и не имеют абстракций, что приводит к необходимости встраивать в них полноценные языки программирования, что в свою очередь создает проблемы безопасности и предсказуемости.
- Участники обсуждения подчеркивают, что вместо того, чтобы изобретать новые конфигурационные языки, следует использовать существующие общеязыковые инструменты (Python, Lisp и т.д.) для конфигурации как код, что позволит избежать проблем с безопасностью и сложностью.
- Некоторые участники также упоминают, что проблема не в синтаксисе или структуре данных, а в отсутствии стандартного языкового сервера для конфигурационных файлов, что делает невозможным автодополнение и переход к определению.
- Также поднимается вопрос о том, что если конфигурационный язык предоставляет возможность встраивать код, то это может быть использовано для вредоносных целей, и вопрос о том, как обеспечить безопасность таких файлов, становится критически важным.
- В конце концов, обсуждение сходится на том, что вместо того, чтобы продолжать изобретать новые конфигурационные языки, следует использовать существующие языки программирования и инструменты, которые уже решают эти проблемы.
YAML document from hell (2023)
YAML позиционируется как удобный для человека формат данных, но на деле оказывается чрезвычайно сложным и полным скрытых ловушек. Его спецификация занимает 10 глав с многоуровневой структурой, в отличие от лаконичного JSON, чья спецификация умещается в шести диаграммах и почти не менялась два десятилетия. YAML активно развивается: версия 1.2 существенно отличается от 1.1, что приводит к разному parsing одних и тех же документов в разных реализациях.
Пример документа с настройками сервера демонстрирует проблемы YAML: числа вида 22:22 могут интерпретироваться как sexagesimal (1342) в версии 1.1, но как строка в 1.2. Якоря (&) и алиасы (*) усложняют чтение, а теги (!) создают угрозу выполнения произвольного кода при загрузке ненадёжных данных. Известная «проблема Норвегии» (неожиданная интерпретация сокращений стран) подчёркивает, что попытки быть «дружелюбным» формат делают его непредсказуемым и опасным.
Комментарии (114)
- Критика YAML за его сложность, неоднозначность и множество подводных камней, таких как проблемы с автоматическим определением типов (например, "no" интерпретируется как
false). - Предложения использовать альтернативы: JSONC, TOML, HCL, Dhall, Jsonnet, CUE или всегда заключать строки в кавычки в YAML для избежания ошибок.
- Обсуждение отдельных проблемных особенностей YAML, таких как якоря/алиасы, сексегесимальные числа и необходимость в линтерах.
- Отмечается, что, несмотря на недостатки, YAML остается популярным из-за удобочитаемости и широкой распространенности.
- Упоминание, что спецификация YAML 1.2 (2009 г.) исправила некоторые проблемы, но многие issues остаются актуальными.