So firstly, I really like this. I find it nicely readable, I like that the structure is almost all you have to write, and I'm quite a fan of lisp-y syntax anywa

So firstly, I really like this. I find it nicely readable, I like that the structure is almost all you have to write, and I'm quite a fan of lisp-y syntax anyway, so no surprises there. The primary reason we choose Jsonnet for the registry library was because it's already become our data munger of choice at GoCardless, and we're keen to limit the number of tools we use to make our work more accessible to people outside our team, along with our new joiners. So while your example works really quite beautifully for this use case, we'd naturally prefer to choose a tool that can work for all our use cases. And Jsonnet has a bit win over the language you've sketched here, in its inheritance and mixin semantics, which allow us to write configuration like complex Kubernetes manifests that are composeable and allow flexible overriding of fields from the caller. Someone else has mentioned dhall-lang in the comments. We looked at this and several alternatives before we began a push for Jsonnet about a year ago- we ended up choosing Jsonnet over these because: - Jsonnet has first-class support in Golang, our primary language for infrastructure code - Everyone who knows JSON already knows how to write valid Jsonnet. This was important, as we expect application engineers to contribute to the Jsonnet config, and asking them to learn something totally novel is a bit much - There were several tools like Ksonnet and Tanka from which we could take inspiration, especially around managing of Kubernetes resources, which was the big motivation behind a total revamp If I were working on a team solo, I think dhall-lang would look really appealing to me. I like strongly typed languages and have a bit of experience in Haskell, so it looks very normal to me. That said, cuelang (https://github.com/cuelang/cue https://github.com/cuelang/cue) looks super interesting, though it has a very different take to Jsonnet. This is a roundabout way of saying I really like your example, and I see our choice of Jsonnet as another version of our choice of Golang: the network effects were too great to ignore, and it's good enough to work for almost everything, if not the best in any one area.