а я говорил, что он плохой?

> Люди хотят зарабатывать деньги - вот так открытие.
не вижу проблем )

Но использовать условную рекламу Prometheus-as-a-service уже нельзя будет

> прочих подвохов
кроме кидания какашек друг в друга

это напоминает историю с ядром линукса и системди

опенсорс он такой

А есть хоть одна имплементация парсинга promql кроме prometheus и victoriametrics? Я к себе встраивал код prometheus-а ради этого, thanos вроде так же делает.  (это кстати достачно больно - оно за собой половину интернета в зависимости тянет.)

Пока выглядит что единственный рассово верный парсер promql - сам прометей.

думаю, что нету
кроме того, Брайан явно ругался на то что реализовать promql сложно поэтому юзайте нашу реализацию, а не пишите свою

https://github.com/prometheus/prometheus/issues/5706
стул сгорел

комментарий там совершенно не к месту обсуждения

я вижу проблему в том, что теперь никто кроме авторов(давайте честно, никто кроме Брайана), не сможет внести изменения в язык. Даже учитывая что это OSS, с высокой долей вероятности, ваш PR будет реджектнут. Посмотрите proposal в котором возникла дискуссия, вспомните тикеты про xrate и xirate. В VM сабмитили issue про неправильно работающий increase: пром рисовал 2, когда VM рисовал 1 - https://github.com/VictoriaMetrics/VictoriaMetrics/issues/237

Я уже приводил выше в пример ClickHouse и SQL. Почему-то разработчики CH решили, что совсем необязательно передавать * в count() для подсчета, как того требует стандарт. CH поддерживает сотни полезнейших функций, которых нет в обычном SQL. И что тут плохого? Стоит ли запрещать теперь использовать имя SQL в документации CH?

ты так говоришь как будто это имеет значение

Именно поэтому sql и не существует как единого языка. Объективно, sql в целом уже больше buzzword, чем реально описание синтаксиса. Хорошо ли это? Мне кажется, это очень сложный вопрос

ну, а PromQL тоже будет баззвордом

т.к. версия PromQL в прометеус 1.0 будет отличаться от PromQL в прометеус 10.0

Эм, нет. Если promql будет разрабатыватся одним источником, у вас всегда будет спецификация языка, пусть даже и из доки прома. В случае sql, спецификация есть, но она не приносит практической пользы

Потому что у каждого он свой

здесь соглашусь

ситуация с sql похожа с интепретацией стандартов с-с++ авторами компиляторов этих языков.

каждая очередная версия субд пишет "теперь мы поддерживаем такие-то и такие-то фичи из sql'99 (или какого-то)"