1.8, migration path to 2.0 was a no-no. Don't remember exact reasons back then but we decided to have wait-and-see approach and see how alternatives grow up as our data generally grows in predictable rate
Also frankly Prometheus support is a massive positive. For better or worse industry standarized on apps using Prometheus as ingest for metrics, and also most of the materials related to that will of course give examples in PromQL
Flux is frankly hieroglyphs for people using it 20 minutes a month like our developers
This is given example on how to raise value in Flux to power of two
|> map(fn: (r) => ({ r with _value: r._value * r._value }))
This is example of that in prometheus
value ^ 2
This is example of calculating percentage in Flux (from their webpage)
Flux looks like it has the opposite design philosophy of PromQL: it makes simple things harder and hard things simpler.
I probably wouldn't default to it, but I've had to solve some issues that were complicated in PromQL that would probably be easier here. E.g. I had to work on a Prometheus monitoring/alerting setup where metrics were all recorded in UTC, but alerts should only fire during local business hours. We ended up with something like a thousand character PromQL query that was utterly illegible (have pity on whatever poor soul has to update it when DST goes away).
Flux looks like it would have a more legible solution to that, though at the cost of making simple analysis way more complicated than it probably needs to be.
The original comment mentioned Influx v3, which doesn't support Flux at all but uses standard SQL instead. Influx v2 still supported InfluxQL from v1, so Flux wasn't essential there either. Flux doesn't seem worth focusing on here.
I've personally found InfluxDB more user-friendly than Prometheus for metrics work, since I've used both at scale and compared my own experiences. The industry leans towards Prometheus nowadays, so I'm used to dealing with Prometheus, but I've found PromQL particularly unpleasant for any kind of complex aggregations. You may disagree, and that's okay. Regular SQL seems far nicer to me in comparison, so it's nice to see Influx v3 focusing on that. I wish Prometheus and VM would develop a standard SQL interface.
VictoriaMetrics doesn't fully support PromQL either; its MetricsQL is only about 73% compatible according to this article[0] that the VM docs link to. I certainly hope that VM took this incompatibility and used it as an opportunity to make MetricsQL more enjoyable to use than PromQL.
AFAIK its not a serious issue for many users and companies who sucssesfuly migrated from prometheus/thanos/influxdb/opentsdb/graphite or even cortex to VictoriaMetrics stack. Think about it ;)
Flux is noisy yes. But promql isn’t exactly the pinnacle of query languages either. Simple stuff is simple, but once you start having more complex queries like sum by/without, it makes absolutely no sense where the parenthesis go and you can place some of the operators on either side of the inner expression.
Also frankly Prometheus support is a massive positive. For better or worse industry standarized on apps using Prometheus as ingest for metrics, and also most of the materials related to that will of course give examples in PromQL
Flux is frankly hieroglyphs for people using it 20 minutes a month like our developers
This is given example on how to raise value in Flux to power of two
This is example of that in prometheus This is example of calculating percentage in Flux (from their webpage) This is how you do it in PromQL Flux is atrocious for "normal users".