Live data from Hacker News

The Dhall Configuration Language

dhall-lang.org

101–110 of 192 posts

Re: The Dhall Configuration Language

#101
post #93

I really hope that one day Google can open source GCL, which so many languages have been inspired by without ever really being as good as it is. They all claim to address pitfalls in GCL but at the end of the day they're just worse than GCL.

Can you say more about what GCL does better than all of the open source ones? Anecdotally, I've heard a lot of GCL horror stories, and many Xooglers have chosen to create things like Jsonnet or Skycfg ( https://github.com/stripe/skycfg ) instead.

It creates nested data without looking like the end format of the data (why I really can't get into jsonnet), it's just obviously its own language but is pretty minimal.

Despite the minimalism it is not necessarily simple. There are features like inheritance and late binding. They can be quite complicated, but the thing that really stands out about GCL is it's not complicated to use. The simple cases are easy, straightforward, and readable. The complicated cases are made possible.

I've used it extensively to store and transform data that has to be manually edited by humans. It's a really great format because I can define all the translation rules which can get pretty complicated, but the complexity I expose to the humans who are writing the data is minimal. But if they need to do some transformations on the data or even just, like, string substitutions...the language is there and they can use it. That's what makes writing your data in a configuration language nice.

(Honestly though I think jsonnet is at least vastly superior to skycfg and the whole starlark ecosystem. I swear I'm so sick of languages that intentionally look like Python without being actual Python!)

Re: The Dhall Configuration Language

#102

I really hope that one day Google can open source GCL, which so many languages have been inspired by without ever really being as good as it is. They all claim to address pitfalls in GCL but at the end of the day they're just worse than GCL.

Isn't CUE basically that? https://cuelang.org/docs/about/#history

Cue doesn't resemble GCL at all.

From that link:

> However, the early design of GCL went for something simpler that coincidentally was also incompatible with the notion of graph unification. This simpler approach proved insufficient, but it was already too late to move to the earlier foreseen approach. Instead, an inheritance-based override model was adopted. Its complexity made the earlier foreseen tooling intractable and they never materialized. The same holds for the GCL offsprings that copied its model.

Needless to say I disagree with the Cue author. I think the inheritance-based override model is fantastic and has made for a great and straightforward configuration language.

Re: The Dhall Configuration Language

#103
post #88

Whatever happened to Puppet, Ansible or Salt frameworks? They were the darling of the devops folks 7 years back.

They are different to Dhall. Puppet, Anisble and Salt are task runners. You give them configuration and they parse the configuration and then run tasks on a destination machine based on the configuration. Dhall is a tool to generate configuration such as json, yams, xml. It’s useful if you have *complex* configurations such as a AWS Cloudformation stack or Kubernetes yaml files.

Ah ok .. thanks for that details. Puppet was also called a configuration manager and it had the capability to generate configuration files of any format in a dynamic way (via support of variables, parameters etc).

Re: The Dhall Configuration Language

#105
post #86

I think Dhall is good at pushing forward some ideas, but honestly I feel like Skylark (Python but not turing complete) just feels like the right way forward. Being able to specify dynamic functionality in a configuration file, when paired with a good configuration API, really makes stuff straightforward IMO. Gunicorn is the best example of this. We have all of these tools that try to propose declarative configuration…

I feel increasing alone in this position but I absolutely hate those Python-like languages.

They look like Python, and they occasionally act like Python. But occasionally they don't, and the mask of looking like Python obscures those times. Then you never really know which Python facilities you have and which ones you don't.

Re: The Dhall Configuration Language

#107

I work on a deployment tooling team. In 2019/2020 we did a deep dive into Dhall vs. Jsonnet^1 for standardizing config and kubernetes templating across my company (Zendesk). We ended up going with Jsonnet (although some Dhall evangelists in the company have kept the dream alive!), which I think is a more approachable language for many, but Dhall has a lot of cool features and good things going for it. Jsonnet is far…

CUE's author invented Borg configuration language or BCL since 2008.

BCL code is the 3rd largest human written code in Google internal code base. In 2019 Aprial, there is 180M lines of BCL, while C++/Java sits at ~300M.

BCL configuration's large scale use probably is beyond any other infra as code use cases known to human.

And the learning and ideas over more than a decade, is manifested in CUE.

Personally, this is enough to convince me to comfortably ignore anything else on the market.

Re: The Dhall Configuration Language

#108

I work on a deployment tooling team. In 2019/2020 we did a deep dive into Dhall vs. Jsonnet^1 for standardizing config and kubernetes templating across my company (Zendesk). We ended up going with Jsonnet (although some Dhall evangelists in the company have kept the dream alive!), which I think is a more approachable language for many, but Dhall has a lot of cool features and good things going for it. Jsonnet is far…

just another 'have you looked at' : https://carvel.dev/ytt/

ytt lets you embed logic via a python-subset (starlark) and also provides "overlays" as a "replace/insert" mechanism. and all valid ytt files are valid yaml files, so they can be passed-through other yaml parsing stages.

Re: The Dhall Configuration Language

#109
post #4

Tried to use it and it didn't fit my usecase: Recursive Types are a bit difficult Looks great otherwise

what kind of software configuration may require recursive types? I've never had to encode trees in my configs so far.

github.com/coralogix/dhall-concourse

Re: The Dhall Configuration Language

#110
post #77

Why wouldn't you use Python as your configuration language?

Have you seen Starlark? It's not too far from that, but safer in a number of ways: https://github.com/bazelbuild/starlark

I said this above as well: ytt (https://carvel.dev/ytt/) lets you embed starlark into valid yaml, among other cute tricks for managing biz-logic in configs.
Post reply on HN