The Dhall Configuration Language • Hacker News Board

Re: The Dhall Configuration Language

#131

Post by valenterry » Fri, Jul 15, 2022, 8:22 AM UTC

baby wrote: post #125

jordanbeiber wrote: post #120

Earlier quoted context omitted.

Wholeheartedly agree - convention before configuration wins with tooling even at modest scale. Larger team(s) using free form yaml configuration and templating quickly becomes messy. Setting a boundary at “configuration” and exposing configuration options to dev teams through settings works really well. It requires you to have a tooling team with a few developers, but it scales!

Convention over configuration is really the future, but not everything follows that philosophy. For example, OCaml codebases are basically a free for all and you can organize things however you want. So with that in mind, you need something to organize and build.

Convention seems to be nice in the beginning. But it's very hard to maintain.

Much better is default configuration. I.e. all "conventions" are explicitly generated into a default-configuration file which you can then change/overwrite/update in whatever way you want.

Re: The Dhall Configuration Language

#132

Post by valenterry » Fri, Jul 15, 2022, 8:26 AM UTC

As much as I love Dhall, I think it's actually better to allow any turing complete programming language and require it to generate the config in a certain format (whatever it is, maybe even dhall).

The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. If it takes too long then we stop it - the same we should do with a Dhall config as well, even if Dhall theoretically will finish in a finite amount of time.

That way everyone can use their preferred language to describe and maintain the configuration. We just have to agree on the format that is being spit out at the end, such as json, yaml, dhall or even a proprietary format.

Re: The Dhall Configuration Language

#133

Post by eru » Fri, Jul 15, 2022, 8:32 AM UTC

ghostwriter wrote: post #76

eru wrote: post #59

Earlier quoted context omitted.

You can do the same, if your language allows a final comma. (And that's what the comment you reply to suggests: make Dhall allow a final comma.)

What's the point of allowing a trailing comma? A delimiter symbol is a delimiter symbol, be it a an opening curly brace or a comma between elements, and one can simply align delimeters.

The main point is to make git diffs smaller when adding or removing elements, I think.

Re: The Dhall Configuration Language

#134

Post by eru » Fri, Jul 15, 2022, 8:32 AM UTC

throwaway894345 wrote: post #82

eru wrote: post #52

Earlier quoted context omitted.

In theory that's true for many of the kinds of Turing-incomplete languages we care about. (Eg it's not true for JPG or for (proper) regular expressions.) From Dhall's docs (emphasis mine): > Note that a “finite amount of time” can still be very long. For example, there are some short pathological programs that take longer than the heat death of the universe to evaluate. The main benefit of evaluation being finite is…

I guess I don’t care much if a configuration language takes a long time in some pathological case (a user writes a loop that doesn’t terminate). Such cases are already too rare to justify a dedicated language. And if the concern is bad actors, then a bad actor wouldn’t have to try to hard to get a Dhall program to run for a long time (copy paste something from the Internet). The more compelling reason to use Dhall is…

Infinite loops are a pretty common bug in my experience.

(Same for the recursive equivalent.)

Re: The Dhall Configuration Language

#135

Post by toastal » Fri, Jul 15, 2022, 8:32 AM UTC

I loved my experience with Dhall from the PureScript community. It prompted me to learn a lot more and I built some small libraries too. My experience was mostly positive. Supporting Unicode is the cherry on top.

Of all my gripes, only two still stick in my mind: • No JavaScript implementation; I want to be able to use it more places, but I always end up having to convert it to JSON to use it • the built-in formatter is way too aggressive; I'm fond of the never-contract-only-expand formatters that don't pressure me to collapse things I don't want and the way it is isn’t to optimize Git diffs where conflicts can arise.

Re: The Dhall Configuration Language

#136

Post by eru » Fri, Jul 15, 2022, 8:34 AM UTC

valenterry wrote: post #132

As much as I love Dhall, I think it's actually better to allow any turing complete programming language and require it to generate the config in a certain format (whatever it is, maybe even dhall). The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run. If it takes too long then we stop it - the same we should do with a Dhall config as well, even if Dhall theoretic…

> The only thing is needed to run the config-generation process in a sandbox and restrict how long it can run.

That's a very brittle restriction at best, and if implemented strictly on time, it's a very flaky on as well.

Re: The Dhall Configuration Language

#137

Post by eru » Fri, Jul 15, 2022, 8:35 AM UTC

bigcat12345678 wrote: post #107

dcchambers wrote: post #41

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 e…

For the record, when I was an SRE at Google, most people I talked to hated BCL with a passion.

Re: The Dhall Configuration Language

#138

Post by eru » Fri, Jul 15, 2022, 8:36 AM UTC

hsn915 wrote: post #115

Relying on configuration files to glue together a huge stack of tools and services in order to produce an end product is a huge mistake. I say it's a mistake fully knowing that nearly everyone in the industry is doing it. Configuration is opaque. Undebuggable. Unmaintainable. By its very nature. No matter what "language" you use for it. You should strive to keep configurable things to an absolute minimum. Although it…

> Configuration is opaque. Undebuggable. Unmaintainable. By its very nature. No matter what "language" you use for it.

What makes you think so? How do you define configuration?

I mean, in the extreme case you can see Python as a configuration language for the behaviour of the Python interpreter. Does that make Python a configuration language? Where do you draw the line?

Re: The Dhall Configuration Language

#139

Post by a-saleh » Fri, Jul 15, 2022, 8:53 AM UTC

makapuf wrote: post #129

fbn79 wrote: post #128

Earlier quoted context omitted.

"Dhall... that you can think of as: JSON + functions + types + imports". Is this Typescript?

IIUC, Dhall is pure and have no side effects

Unless you count the ability to do imports from around the web. But you can still make it side-effect-less by using caching and semantinc hashes on those imports?

Re: The Dhall Configuration Language

#140

Post by otabdeveloper4 » Fri, Jul 15, 2022, 9:01 AM UTC

lmm wrote: post #122

la64710 wrote: post #88

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

Kubernetes ate their lunch, mostly.

No. Tools like Ansible are just wrappers around ssh when you need to run a command across many servers. They don't do anything k8s does.