Json lacks comments, templating, evaluation, types, and lots of other features. Having something generating a valid config is great, especially if you're generating multiple configs in different format from the same place. For example being able to configure SSH, nginx and some other services from nixos config is amazing.

Well, Dhall provides something between JSON and a Turing complete language that can make a lot of configuration much quicker to write, if you can hack the functional syntax. Pkl is probably a similar concept.

http://dhall-lang.org/

I love Dhall. It's purposefully not Turing complete (which is somewhat difficult to achieve in a language design) and I love that fact.

Because there are a thousand ways to describe the same thing in JSON. This:

    city = {
        "id": 3,
        "name": "Foo",
        "lat": 3.555,
        "long": 4.11,
    }

Is the same as:

    city = {
        "id": "3",
        "name": "Foo",
        "coordinates": [3.555, 4.11]
    }

But you want to normalize that.

Something like Cuelang will:

- Define the schema that will let you know what you should put inside.

- Allow you to inflate that schema into a full file, providing only the values.

- Will generate always a correct file, with no typo, or format error.

- Will check that the data is correct and tell you if there are any errors.

- Is note theoretically tied to a particular run time or stack.

Sounds like a job for JSON Schema

https://json-schema.org

Jumping back and forth between a JSON schema and writing valid JSON is not a very fun task

In your example, how is this different than incorrectly creating the data structure in any format ?

I'll be looking into cue, but how does it solve that problem ?

In general (not just limited to Pkl), I think the advantage is that you get IDE support like autocomplete and compile time checks. Pkl seems to borrow some features from JSONSchema/SHACL for example where one can also add validations like "value must be bigger than 20 and lower than 100" so when you configure a component incorrectly, it can throw a good error message before deployment.

Writing raw JSON is very error prone and you have to repeat yourself a lot. I think everyone who has worked with it has had some surprises, I certainly have.

Similar to why do we write Python instead of assembly, or why do relational databases typically have things like datatypes and constraints?

The amount of problems I've had with JSON in my career makes me think almost anything could be better than it. There's so many weird edge cases in the JSON spec that you can hit that it just becomes endless levels of hair pulling.

Have you tried YAML? :-)

NOrway, I haven't.

Can you share some examples?

which edge cases?

Because Pkl makes it trivial to write templates and transforms. So you can write a Pkl schema that only requires a minimum set of fields, then auto generate a complete configuration.

This is most useful when dealing with tools like k8s where deploying a single application might involve 3-10 separate manifests (Deployment, Service, NetworkPolicy, HttpRoute, Autoscaler etc etc). With Pkl you can easily write a simple template that only requests the minimum needed to define an “app” (e.g. name, namespace, mixins for sidecars) and have Pkl generate all the needed manifests for you.

Really Pkl should be seen as a language for quickly building templating tools like Helm. But with type safety by default, and no need for horrible indent hacks.