github-desktop VS grafonnet-lib

Yes that's a common problem with config languages. They're torn between competing priorities:

1. Fast to parse with a small engine, good error messages, safe to evaluate.

2. Powerful, can express config with arbitrary logic.

In Conveyor we try an alternative approach. The config is HOCON, which is a superset of JSON syntax designed for human readability/writability/convenience first and foremost, so it's got a very nice and clean feel to it. You can see an example here:

https://github.com/hydraulic-software/github-desktop/blob/co...

It can be parsed with a normal-sized config library and the errors you get are reasonable.

But then what if you hit the limits of what it can express? We added support for "hashbang includes":

    include "#!script.js"

I honestly... don't know. I have been using Jsonnet to programatically generate Grafana dashboards, because AFAIK the only official library to generate them is written in Jsonnet [1].

In my experience, it works, but it doesn't really give me any distinct advantage. Maybe for things that look almost like JSON it'd be helpful, but the moment you start dealing with more complex generations you start finding lack of typing, lack of IDE support, lack of easy debugging, etc, fairly problematic. For example, something I really dislike is that due to how the expressions are evaluated, the only way to add debug/trace statements is to use them to "transform" a value you're going to use, if you don't use the result of the trace in the final output, the trace does not appear.

1: https://github.com/grafana/grafonnet-lib

Jsonnet

I recently started working with Grafana for my bachelor thesis. I want to evaluate scripting libraries like grafonnet to create dashboards.