Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dhall Configuration Language

dhall-lang.org

Post reply on HN
Print view View original

151–160 of 192 posts

Re: The Dhall Configuration Language

#151

Post by declnz »

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…

Whilst I like the look of Cue... this argument reminds me of the Kubernetes trap ( We should use it... because Google does it and they're huuuuuuuge don't you know etc )

Re: The Dhall Configuration Language

#152

Post by ghostwriter »

thayne wrote: post #116

I like a lot of the ideas in dhall, but but I disagree with some of the design decisions. The syntax for objects with dynamic keys seems unnecessarily verbose. The arithmetic capabilities are very restricive. No subtraction, division, or modulo. Addition and multiplication only work on Natural. No numeric comparison. = And != Only work on booleans. There isn't really much motivation given for why it is so restricted.…

> Maybe I'm missing something, but it seems like if a type has a lot of optional fields, which is pretty common, you have to explicitly pass None for all of them.

You can specify defaults for you record types via Type/default pattern https://github.com/Gabriella439/dhall-manual/blob/develop/ma...

Re: The Dhall Configuration Language

#153

Post by ghostwriter »

valenterry wrote: post #142
eru wrote: post #136

Earlier quoted context omitted.

> 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.

How so? Normally, generating a config, even a big one, is a matter of milliseconds even for slow languages. We are not talking about applying the config - we are just talking about using some inputs (variables) and generating a string / text-file that we return to the entitiy that then validates and uses the config. Not sure why that would be flaky.

Generating a config may include downloading a number of remote definitions, their evaluation & caching for future reuse (Dhall does that, Nix too), which doesn't fit into milliseconds threshold on the first run.

Re: The Dhall Configuration Language

#155

Post by p_l »

pmayrgundter wrote: post #144
eru wrote: post #137

Earlier quoted context omitted.

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

Same here. It did some cool stuff but really bent your mind. Agree with the other comment that the amount of it at Goog should have a mixed interpretation. Obviously it was useful, but although Google systems were complicated, it still doesn't seem right that it's on the same magnitude as the main system langs.

From talking with people who used both BCL, JSonnet and CUE, CUE is an attempt to learn and fix the things that made BCL hated.

Re: The Dhall Configuration Language

#156

Post by thethethethe »

infogulch wrote: post #145
thethethethe wrote: post #123

Earlier quoted context omitted.

The number of lines of BCL at Google says little-to-nothing about the efficacy of the language itself, it's more of a reflection of the complexity and scale of the _systems_ its used to configure.

It's it a good language? Unknown. Can it be used to successfully build and maintain configuration at extremely large volume and complexity scales? Yes. Also we're not talking about using this language, but its spiritual successor.

> It's it a good language? Unknown.

I have personally written several thousand lines GCL (the generic version of BCL used at Google) and I can say that it can be pretty frustrating.

The difficulty and complexity of defining configurations using it really depends on the system you are configuring since you are (generally) just defining a set of static fields that are packaged into a protobuf and fed into whatever system you are working with.

Outside of syntax issues, it's up to the system you are configuring to provide concise config semantics and helpful error messages

Re: The Dhall Configuration Language

#157

Post by thethethethe »

rtpg wrote: 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…

Is skylark (now called starlark btw) general purpose? Its my understanding that its largely used for configuring bazel.

Re: The Dhall Configuration Language

#158

Post by ghostwriter »

doliveira wrote: post #148
ghostwriter wrote: post #78

Earlier quoted context omitted.

both symbols are delimiters, one can choose to align them together even when they are not the same character. Opening and closing braces aren't the same character either, but people have been aligning them for ages, I don't see a reason why commas, while being part of the same expression, should not follow the same principle.

For me it's not about being the same character (like you've mentioned, opening and closing braces aren't either), it's about commas and braces indicating different things in the hierarchy. Not to mention the symmetry breaking: an opening brace together with data in a line, then a lonely one at the bottom.

In a series of declarations, the lonely closing brace at the bottom can be treated as a substitute for an empty line between two entries, as it produces a similar sparse spacing.

Re: The Dhall Configuration Language

#159

Post by tr33house »

Sahbak wrote: post #119
tr33house wrote: post #12

anyone using this for kubernetes config generation? What's been your experience?

Don't. Use helm, kustomize or a decent code language. Dhall will constrict, slow you down, make onboarding a nightmare, and ultimately be as brittle as other alternatives (Only it's harder to find where it broke). I cannot advocate against dhall enough.

this is what I thought too. I've enjoyed working with helm and totally recommend it but was wondering if I'd missed something. A templating language and not an actual programming language seems to be the right balance for config

Re: The Dhall Configuration Language

#160

Post by IshKebab »

jordanbeiber wrote: post #120
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…

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!

One problem with convention is that it isn't discoverable. At least config files guide you to where to look for stuff.

But even so I think you're probably right that convention is better because it forces everyone to use the same structure for stuff.

Post reply on HN