Спасибо за подробный контр-аргумент - это полезнее общей критики, потому что чётко очерчивает границу применимости.
И да, вы правы: на 3-4 тысячах ключей с тремя окружениями и разделением секретов Ktav вам ничего не даст сверх того, что дают JSON/YAML/TOML. Формат этого не решает и не пытается. Он про другое - про конфиг, который человек пишет и читает руками: сервис, CLI, небольшое приложение. Там, где конфигурация становится системой со своим наследованием, оверлеями и секрет-менеджментом, нужен не формат, а инструмент: Helm/Kustomize, CUE, Consul, Vault. Выбор формата на таком масштабе - вопрос десятый.
Про include / interpolation / merge - это сознательно вне формата, а не недоделка. Как только внутрь синтаксиса заходит include или подстановка переменных, файл перестаёт читаться сам по себе, и появляется порядок вычисления, который надо описывать и реализовывать одинаково во всех семи биндингах. Мы решили, что этот слой живёт в приложении: конфиг из файла, env поверх, секреты инжектятся отдельно. Скучно, зато предсказуемо.
Про схемы вы попали в реальный пробел - своего языка описания схем у Ktav нет, и это честное ограничение.
Но одно уточнение: модель данных у Ktav ровно JSON-овская - те же скаляры, массивы, объекты, null, bool, без тегов и якорей. Поэтому JSON Schema применима к результату разбора: распарсили .ktav в структуру и валидируйте тем же валидатором, что и для JSON. Отдельная схема под формат не нужна - преимущество JSON здесь наследуется, а не теряется.
Про вкусовщину спорить не буду. Кавычки и запятые действительно вопрос привычки, и если они вам не мешают - формат вам не нужен, это нормальный исход. Он вырос из личного раздражения, а не из уверенности, что так лучше всем, и 20 лет за клавитурой накопили разражение в бесконечных танцах пальцев с шифтами)
Спасибо - и отдельное спасибо за ПР, это редкий жанр комментария.
Про кросс-языковые команды верно, цена именно такая, как вы описали: .so рядом и прочее. Платим её сознательно, ради одинакового поведения везде и производительности Rust.
Теперь про ::int / ::float. Идея понятна и ложится на существующий синтаксис, но в 0.5.0 мы убрали ровно такие маркеры - были :i и :f.
Главная причина - типизированные языки всё равно сами решают, какого типа получать значение. Целевой тип задаёт структура, в которую десериализуют, а не документ: serde в Rust, struct в Go, класс в C# приведут port к u16 независимо от того, как парсер классифицировал скаляр. Маркер в конфиге дублировал то, что уже объявлено в коде, и добавлял вопрос, что делать, когда он противоречит форме.
Плюс ощущение, что для конфигов небольшого ПО текущих возможностей хватает - формат задумывался именно для удобных конфигураций, а не для передачи данных.
Отчасти ту же боль закрывает как раз ваш parse_strict, только с другой стороны: он не даёт форме молча поехать.
Спасибо, что заглянули! Видимо в статье разница с JSONC не бросилась в глаза. Есть сравнительаня таблица на сайте - ktav-lang.github.io (в комментарий пока не разобрался как вставлять таблицы), опишу словами:
JSONC - это JSON плюс комментарии, и всё, остальное как в обычном JSON: кавычки на ключах и строках обязательны, запятые обязательны.
В Ktav иначе: кавычки на ключах и строках не нужны вообще (кроме ::, когда явно хочешь застолбить строку), запятые нужны только если пишешь массив или объект в одну строку, комментарии свои - ##, а для многострочного текста есть отдельный блок в скобках вместо \n внутри одной строки в кавычках.
На примере с приватным ключом. В JSON/JSONC он склеен в одну строку через \n:
{
// тестовый ключ, не для прода
"private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKC...\n-----END RSA PRIVATE KEY-----"
}
В Ktav - отдельный блок, построчно как есть:
## тестовый ключ, не для прода
private_key: (
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKC...
-----END RSA PRIVATE KEY-----
)
Include с файлом секрета и ENV(‘LOG_LEVEL’, ‘info’) внутри конфига - сознательно не входит в формат. Ktav - только слой данных, без include/expressions/interpolation, как и JSON с TOML: добавишь интерполяцию - формат превращается в мини-язык со своей семантикой выполнения.
Стремился к минимализму - “Ktav простой и хороший, он не совершенный, но лучший для конфигов”. Получилось сделать его таким или нет - покажет время.
Возможно параллельно будет какой-нибудь ktav_plus - со ссылками, переменными и прочим, но основной формат останется в минимализме, как json
По сути это уже встроено - только как метод тестирования, не как продукт. Тест-спека - это пары “вход на Ktav → ожидаемый JSON”: https://github.com/ktav-lang/spec/tree/main/versions/0.6/tests/valid Берёте любой .ktav - рядом его .json-эквивалент. Транслятор, покрытый тестами на все краевые случаи, - это и есть наш эталонный Rust-парсер.
Почему всё же выбрал FFI в 7 языков, а не “отдай JSON нативному парсеру” - довод один, про скорость. Цель была - парсинг вровень с serde_json; по факту медленнее раза в два, но это наносекунды, я считаю результат хорошим. А вот лишний проход через JSON-текст (сериализовать → распарсить второй раз) - уже отдельная стоимость поверх, которая на горячем пути (частые перечитывания, много мелких конфигов) будет заметна. На конфиге, который читается раз при старте, - без разницы.
И обычно: “транслятор + родной парсер” - ровно то, что делают на старте нового формата, и это хорошая стратегия при ограниченности ресурсов. Я сделал наоборот - вложился в 7 FFI-биндингов за полтора месяца, до первого внешнего пользователя. Риск, чего уж там.
Лёгкий транслятор в чистый JSON отдельно от биндингов - хорошая идея, завёл issue: https://github.com/ktav-lang/spec/issues/2. В следующих версиях рассмотрю подробнее как с сней быть.
И да: без всего, что Ktav даёт сверх модели JSON, формулировка была бы именно такой - не 15-й стандарт, а просто приятный способ печатать JSON руками)
Занимаюсь активной разработкой нескольких проектов - очень много temp артефактов плодит это, и всё складируется в папку профиля temp
+ Рабочий стол давно не приводил в впорядок, + загрузки.
Оказалось, что часть из этих артефактов сканируется антвирусом при старте и еще что-то их перебирало, если не ошибаюсь. Скорее всего не смогу уточнить, это было пару месяцев назад, а Клод подчистил старые сесиии.
Недавно пришла идея реализовать систему контролля версий, которая будет хранить дерево объектов на базре AST дерева кода (и их историю). Тогда на каждую деталь кода можно будет вести любую историю любых мета-данных. Это бы сильно улучшило работу с кодом, мне кажется.
Работа мастштабная, но хочется взяться в этой жизни
Сама шкала "нормальности"/здоровья зависит от общества и эпохи? Вопрос с подвохом. Это не отменяет реальной пользы лечения - цифры говорят за себя, но интересно, насколько критерии расстройств универсальны или, напротив, культурно обусловлены.
У меня как-то логин в систему стал длиться около 60 секунд. Запустил Клод, попросил разобраться. Он установил несколько диагностических утилит, включил логирование. Через 3 перезагрузки и со снятием логов всё прояснилось. Имы все исправили.
Принчина была в распухшем профиле, windows defender, MariaDB и еще пару-тройка чего-то еще.
В итоге логин стал диоться 5-10 секунд.
Так же с Клодом отладил несколько синих экранов (BSOD).
Очень радует эта эпоха, когда сложне задачи можно решить без глубокого погружения в тему
Всегда расчесывал до конца и сейчас так делаю. Не могу остановиться и дохожу до победного.
Сейчас понимаю всё, что со мной происходит - я вскрывают кожу, выдаливаю все жидкости и зуд проходит раз и навсегда. Тянет думать, что так избавляюсь от результатов впрыскивания чужеродных веществ.
Конечно, чистые руки и чистая кожа - это мега-важно в этом способе. Ни к чему не призываю.
Спасибо за подробный контр-аргумент - это полезнее общей критики, потому что чётко очерчивает границу применимости.
И да, вы правы: на 3-4 тысячах ключей с тремя окружениями и разделением секретов Ktav вам ничего не даст сверх того, что дают JSON/YAML/TOML. Формат этого не решает и не пытается. Он про другое - про конфиг, который человек пишет и читает руками: сервис, CLI, небольшое приложение. Там, где конфигурация становится системой со своим наследованием, оверлеями и секрет-менеджментом, нужен не формат, а инструмент: Helm/Kustomize, CUE, Consul, Vault. Выбор формата на таком масштабе - вопрос десятый.
Про include / interpolation / merge - это сознательно вне формата, а не недоделка. Как только внутрь синтаксиса заходит include или подстановка переменных, файл перестаёт читаться сам по себе, и появляется порядок вычисления, который надо описывать и реализовывать одинаково во всех семи биндингах. Мы решили, что этот слой живёт в приложении: конфиг из файла, env поверх, секреты инжектятся отдельно. Скучно, зато предсказуемо.
Про схемы вы попали в реальный пробел - своего языка описания схем у Ktav нет, и это честное ограничение.
Но одно уточнение: модель данных у Ktav ровно JSON-овская - те же скаляры, массивы, объекты, null, bool, без тегов и якорей. Поэтому JSON Schema применима к результату разбора: распарсили .ktav в структуру и валидируйте тем же валидатором, что и для JSON. Отдельная схема под формат не нужна - преимущество JSON здесь наследуется, а не теряется.
Про вкусовщину спорить не буду. Кавычки и запятые действительно вопрос привычки, и если они вам не мешают - формат вам не нужен, это нормальный исход. Он вырос из личного раздражения, а не из уверенности, что так лучше всем, и 20 лет за клавитурой накопили разражение в бесконечных танцах пальцев с шифтами)
Спасибо - и отдельное спасибо за ПР, это редкий жанр комментария.
Про кросс-языковые команды верно, цена именно такая, как вы описали: .so рядом и прочее. Платим её сознательно, ради одинакового поведения везде и производительности Rust.
PR влит, релиз для Rust опубликован - 0.6.2: https://crates.io/crates/ktav
Теперь про ::int / ::float. Идея понятна и ложится на существующий синтаксис, но в 0.5.0 мы убрали ровно такие маркеры - были :i и :f.
Главная причина - типизированные языки всё равно сами решают, какого типа получать значение. Целевой тип задаёт структура, в которую десериализуют, а не документ: serde в Rust, struct в Go, класс в C# приведут port к u16 независимо от того, как парсер классифицировал скаляр. Маркер в конфиге дублировал то, что уже объявлено в коде, и добавлял вопрос, что делать, когда он противоречит форме.
Плюс ощущение, что для конфигов небольшого ПО текущих возможностей хватает - формат задумывался именно для удобных конфигураций, а не для передачи данных.
Отчасти ту же боль закрывает как раз ваш parse_strict, только с другой стороны: он не даёт форме молча поехать.
Благодраю за участие! Очень рад первому ПР.
Оказывается еще и баг в темной теме со списоком. Исправил. Спасибо!
По INI - не каждый конфиг может сконвертироваться в INI. Это не баг. Ниже на скрине показывается корректная ошибка об этом.
Спасибо, что заглянули! Видимо в статье разница с JSONC не бросилась в глаза. Есть сравнительаня таблица на сайте - ktav-lang.github.io (в комментарий пока не разобрался как вставлять таблицы), опишу словами:
JSONC - это JSON плюс комментарии, и всё, остальное как в обычном JSON: кавычки на ключах и строках обязательны, запятые обязательны.
В Ktav иначе: кавычки на ключах и строках не нужны вообще (кроме
::, когда явно хочешь застолбить строку), запятые нужны только если пишешь массив или объект в одну строку, комментарии свои -##, а для многострочного текста есть отдельный блок в скобках вместо\nвнутри одной строки в кавычках.На примере с приватным ключом. В JSON/JSONC он склеен в одну строку через
\n:В Ktav - отдельный блок, построчно как есть:
Include с файлом секрета и ENV(‘LOG_LEVEL’, ‘info’) внутри конфига - сознательно не входит в формат. Ktav - только слой данных, без include/expressions/interpolation, как и JSON с TOML: добавишь интерполяцию - формат превращается в мини-язык со своей семантикой выполнения.
Стремился к минимализму - “Ktav простой и хороший, он не совершенный, но лучший для конфигов”. Получилось сделать его таким или нет - покажет время.
Возможно параллельно будет какой-нибудь ktav_plus - со ссылками, переменными и прочим, но основной формат останется в минимализме, как json
Спасибо, приятно слышать!
По сути это уже встроено - только как метод тестирования, не как продукт. Тест-спека - это пары “вход на Ktav → ожидаемый JSON”: https://github.com/ktav-lang/spec/tree/main/versions/0.6/tests/valid Берёте любой .ktav - рядом его .json-эквивалент. Транслятор, покрытый тестами на все краевые случаи, - это и есть наш эталонный Rust-парсер.
Почему всё же выбрал FFI в 7 языков, а не “отдай JSON нативному парсеру” - довод один, про скорость. Цель была - парсинг вровень с serde_json; по факту медленнее раза в два, но это наносекунды, я считаю результат хорошим. А вот лишний проход через JSON-текст (сериализовать → распарсить второй раз) - уже отдельная стоимость поверх, которая на горячем пути (частые перечитывания, много мелких конфигов) будет заметна. На конфиге, который читается раз при старте, - без разницы.
И обычно: “транслятор + родной парсер” - ровно то, что делают на старте нового формата, и это хорошая стратегия при ограниченности ресурсов. Я сделал наоборот - вложился в 7 FFI-биндингов за полтора месяца, до первого внешнего пользователя. Риск, чего уж там.
Лёгкий транслятор в чистый JSON отдельно от биндингов - хорошая идея, завёл issue: https://github.com/ktav-lang/spec/issues/2. В следующих версиях рассмотрю подробнее как с сней быть.
И да: без всего, что Ktav даёт сверх модели JSON, формулировка была бы именно такой - не 15-й стандарт, а просто приятный способ печатать JSON руками)
в текущих реалиях их надо делать под каждой станцией метро и еще где-то глубоко под горами
Занимаюсь активной разработкой нескольких проектов - очень много temp артефактов плодит это, и всё складируется в папку профиля temp
+ Рабочий стол давно не приводил в впорядок, + загрузки.
Оказалось, что часть из этих артефактов сканируется антвирусом при старте и еще что-то их перебирало, если не ошибаюсь. Скорее всего не смогу уточнить, это было пару месяцев назад, а Клод подчистил старые сесиии.
Недавно пришла идея реализовать систему контролля версий, которая будет хранить дерево объектов на базре AST дерева кода (и их историю). Тогда на каждую деталь кода можно будет вести любую историю любых мета-данных. Это бы сильно улучшило работу с кодом, мне кажется.
Работа мастштабная, но хочется взяться в этой жизни
централизованные точки отказа - это то, чего пытались избежать при создании интернета. Хорошо бы всегда это помнить и следовать этому
знаю людей, у которых ощущения 1/10 не в пользу здоровых. Примечательно, что себя они при этом относят к 9 больным
Сама шкала "нормальности"/здоровья зависит от общества и эпохи? Вопрос с подвохом. Это не отменяет реальной пользы лечения - цифры говорят за себя, но интересно, насколько критерии расстройств универсальны или, напротив, культурно обусловлены.
У меня как-то логин в систему стал длиться около 60 секунд. Запустил Клод, попросил разобраться. Он установил несколько диагностических утилит, включил логирование. Через 3 перезагрузки и со снятием логов всё прояснилось. Имы все исправили.
Принчина была в распухшем профиле, windows defender, MariaDB и еще пару-тройка чего-то еще.
В итоге логин стал диоться 5-10 секунд.
Так же с Клодом отладил несколько синих экранов (BSOD).
Очень радует эта эпоха, когда сложне задачи можно решить без глубокого погружения в тему
Всегда расчесывал до конца и сейчас так делаю. Не могу остановиться и дохожу до победного.
Сейчас понимаю всё, что со мной происходит - я вскрывают кожу, выдаливаю все жидкости и зуд проходит раз и навсегда. Тянет думать, что так избавляюсь от результатов впрыскивания чужеродных веществ.
Конечно, чистые руки и чистая кожа - это мега-важно в этом способе. Ни к чему не призываю.